Выберите оценочный ордер "where clause"

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

Один из способов управления порядком оценки - это выражение 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

Ответ 6

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

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

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

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

Ответ 7

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

Выберите num из таблицыA WHERE TableA.num < 0 И 1/0 = 10.

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

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