Выберите, где порядок оценки предложения

Нет никаких гарантий для порядка оценки. Оптимизатор попытается найти наиболее эффективный способ выполнения запроса, используя доступную информацию.

В вашем случае, поскольку c индексируется, а d нет, оптимизатор должен просмотреть индекс, чтобы найти все строки, соответствующие предикату c, а затем извлечь эти строки из данных таблицы, чтобы оценить предикат d.

Однако, если он определяет, что индекс для c не очень избирательный (хотя в вашем примере это не так, столбец гендера редко индексируется с пользой), он все равно может принять решение о сканировании таблицы.

Чтобы определить порядок выполнения, вы должны получить план объяснения для вашего запроса. Однако имейте в виду, что этот план может измениться в зависимости от того, что оптимизатор считает лучшим запросом прямо сейчас.

SQL Server создаст оптимизированный план для каждого выполняемого оператора. Вам не нужно заказывать предложение where, чтобы получить это преимущество. Единственная гарантия, которую вы имеете, заключается в том, что она будет запускать операторы в следующем порядке:

SELECT A FROM B WHERE C
SELECT D FROM E WHERE F

запустит первую строку перед второй.

Одним из способов управления порядком вычисления является выражение CASE.

[Редактировать]

Популярное мнение, которое я пытался выразить, было следующим:

Вы не можете зависеть от порядка оценки выражения для таких вещей, как «ГДЕ ИЛИ», поскольку оптимизатор может выбрать план, который оценивает второй предикат перед первым. Но порядок оценки выражений в операторе CASE фиксирован, поэтому вы можете полагаться на детерминированную оценку короткого замыкания оператора CASE.

Это становится немного сложнее, как описано на сайте ниже:

http://blogs.msdn.com/b/bartd/archive/2011/03/03/don-t-depend-on-expression-short-circuiting-in-t-sql-not-even-with-case.aspx

Вы можете просмотреть план выполнения запроса и определить, что он на самом деле пытается сделать. Я думаю, что механизм запросов SQL Server должен выполнять этот тип сканирования и разумно преобразовывать его в операции. Например, если вы сделаете «дорогую операцию И ложь», она быстро будет оценена как ложь.

Из того, что я узнал, то, что вы печатаете, отличается (и может быть) от того, что на самом деле выполняется. Вы просто сообщаете серверу, каких результатов вы ожидаете. То, как он получает ответ, не коррелирует слева направо с кодом, который вы предоставляете.

Если вы хотите убедиться, вы можете проверить план выполнения запроса. План выполнения, который строит/оптимизирует MSSQL, достаточно умен, чтобы проверять индексированный столбец перед столбцом varchar.

Короткое замыкание выполняется, когда условие, на которое мы ссылаемся, включает только литералы или константы. Так, например, скажем, у нас есть таблица TableA, в которой есть столбец num со всеми положительными числами от 1 до 10, а затем, если я напишу этот запрос.

Выберите число из таблицы A, ГДЕ TableA.num ‹ 0 AND 1/0 = 10.

Это приведет к ошибке.

Достаточно ли умен компилятор, чтобы определить, что мое второе предложение состоит из констант, поэтому он должен оценить это перед оценкой предложения, которое требует любого сканирования из таблицы или индекса?

Оптимизатор запросов MS SQL Server делает короткое замыкание, да. Гарантировано.

Запустите это:

select 1 where 1 = 0 and 1 / 0 = 10

Он будет работать нормально и без ошибок, даже если вы делите на ноль, потому что оптимизатор запросов укоротит оценку предложения where. Это имеет значение для любого предложения where, где вы используете «и», а одна из частей и является константой.