Вопрос SQL: имеет ли значение порядок предложения WHERE?

Question

С точки зрения производительности, имеет ли значение порядок моих операторов SQL WHERE?

Например

SELECT ... FROM ...
WHERE a > 1
AND b < 2

Это будет быстрее / медленнее, чем

SELECT ... FROM ...
WHERE b < 2
AND a > 1

Давайте также предположим, что я заранее знаю, что a > 1 сузит набор результатов больше всего.

Кроме того, имеет ли значение, если я присоединяюсь к двум или более таблицам в порядке своих операторов WHERE?

Answer 1

Теоретически разницы нет.

Иногда, особенно с более простыми оптимизаторами, существуют различия в плане запросов в зависимости от порядка предложений в предложении WHERE. Есть довольно сильный аргумент, что такие различия являются симптомом ошибки.

Аналогичные комментарии применимы и к порядку присоединения. Порядок объединений не должен иметь значения - для объединений одного типа. Ясно, имеет ли значение таблица Table2 с внутренним или внешним соединением с другой таблицей Table1 - и имеет значение, является ли она Table1 LEFT JOIN Table2 или Table1 RIGHT JOIN Table2 или Table1 FULL JOIN Table2. Но для ряда операций INNER JOIN последовательность не должна иметь значения. Порядок обработки может быть в некоторой степени принудительным, если вы имеете дело с цепочкой объединений.

Уточнение (снова) - рассмотрим:

(Table1 AS t1 JOIN Table2 AS t2 ON t1.pkcol = t2.fkcol) AS j1
JOIN
(Table3 AS t3 JOIN Table4 AS t4 ON t3.pkcol = t4.fkcol) AS j2
ON j1.somecol = j2.anothercol

Как написано, программист ожидает, что объединения в (t1, t2) и (t3, t4) будут выполнены до объединения в (j1, j2), но оптимизатор может выполнить объединения по-другому. Например, если j1.somecol получен из Table1, а j2.anothercol получен из Table4, оптимизатор может выбрать объединение в Table1.SomeCol = Table4.AnotherCol среди других объединений. На этот тип проблем могут влиять условия фильтрации в предложении WHERE, а также наличие или отсутствие соответствующих индексов в различных таблицах. Именно здесь статистика может сыграть большую роль в том, как оптимизатор создает план запроса.

Answer 2

Нет, это не так. Большинство современных серверов SQL включают в себя оптимизатор запросов, который рассматривает все вероятные (*) способы разрешения запроса, и при этом старые серверы могут получать подсказки в зависимости от порядка в предложении SELECT, а новые серверы - нет.

Порядок СОЕДИНЕНИЙ, с другой стороны, все еще имеет большое значение.

Редактировать: См. Ответ Джонатана Леффлера, поскольку он предоставляет дополнительную информацию, в частности, касающуюся порядка соединений. Спасибо тебе, Джонатан!

Редактировать: (*) Вероятность и вероятность: Как указал Эриккален, оптимизатор не рассматривает все из возможных способами, благодаря [довольно хорошей] эвристике, закодированной в его логике, он будет оценивать только вероятные планы на основе статистики, которую он хранит для базовых индексов. Для каждого из планов он считает, что общая стоимость оценивается (или частично так, когда частичные затраты легко превышают общую стоимость другого плана [обрезка]), и именно так в конечном итоге выбирается эффективно используемый план. Несмотря на то, что общие принципы, используемые оптимизаторами SQL-запросов, хорошо известны, тонкости их реализации приводят к множеству различных поворотов.

Answer 3

См. Ниже и перейдите по ссылке (длинная статья, но стоит прочитать):

SQL Server Transact-SQL ГДЕ

Если предложение WHERE включает в себя несколько выражений там вообще нет выигрыш в производительности при заказе различные выражения в любом определенный порядок. Это потому что Оптимизатор запросов SQL Server делает это для вас, экономя ваши усилия. Там Есть несколько исключений, которые обсуждаются на этом веб-сайте. [7,0, 2000, 2005] Добавлено 1-24-2006

Answer 4

Это зависит от СУБД. Сам SQL ничего не говорит о том, как должен выполняться запрос. Это зависит от конкретной реализации.

Если бы ваша СУБД имела очень упрощенную модель последовательной интерпретации запроса, то размещение> 1 в вашем примере (очевидно) было бы быстрее - потому что СУБД сделала бы два прохода, из которых второй проход проходит через гораздо меньшую ResultSet.

Answer 5

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

Answer 6

Если это из той же таблицы, и запрос такой же простой, как ваш пример, то нет, это не имеет значения. По мере того, как вы усложняетесь и связываете больше таблиц, это возможно.