С точки зрения производительности выполняется ли порядок моих инструкций SQL WHERE?
Например
SELECT ... FROM ...
WHERE a > 1
AND b < 2
Будет ли это быстрее или медленнее, чем
SELECT ... FROM ...
WHERE b < 2
AND a > 1
Предположим также, что я заранее знаю, что a > 1 будет сужать множество результатов.
Кроме того, имеет значение, если я присоединяюсь к двум или более таблицам в порядке моих инструкций WHERE?
В теории нет разницы.
Иногда, особенно с более простыми оптимизаторами, различия в плане запроса зависят от порядка предложений в предложении WHERE. Там умеренно сильный аргумент, что такие различия являются симптомами ошибки.
Подобные комментарии также относятся к порядку объединения. Порядок объединений не должен иметь значения - для объединений одного типа. Очевидно, что таблица Table2 является внутренней или внешней, соединенной с другой таблицей. Таблица 1 имеет значение - и имеет значение, является ли она 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 происходит из таблицы 1 и j2.anothercol получается из таблицы 4, оптимизатор может выбрать соединение в таблице 1.SomeCol = Table4.AnotherCol по любому из других объединений. На эту проблему могут влиять условия фильтра в предложении WHERE, а также наличие или отсутствие соответствующих индексов в разных таблицах. Здесь статистика может сыграть большую роль в том, как оптимизатор генерирует план запроса.
Нет, это не так. Большинство современных SQL-серверов включают оптимизатор запросов, который рассматривает все правдоподобные (*) способы разрешения запроса, а старые серверы могут отображать подсказки на основе порядка в предложении SELECT, но более новые серверы этого не делают.
Порядок JOINs, с другой стороны, все еще имеет значение в большей степени.
Изменить: Обратите внимание на ответ Джонатана Леффлера, поскольку он предоставляет дополнительную информацию, в частности, о порядке СОЕДИНЕНИЙ. Спасибо, Джонатан!
Изменить: (*) Правдоподобно против возможного: Как отметил Эриккален, оптимизатор не рассматривает все возможные способы, благодаря [довольно хорошим ] эвристика, закодированная в своей логике, она будет оценивать правдоподобные планы, основываясь на статистике, которую она хранит для базовых индексов. Для каждого из планов он считает, что общая стоимость оценивается (или частично так, когда частичные затраты легко превышают общую стоимость другого плана [обрезка]) и что, как эффективно используется план, в конечном счете выбирается. Хотя общие принципы, используемые оптимизаторами SQL-запросов, хорошо известны, тонкости их реализации вносят много разных поворотов.
См. ниже и следуйте ссылке (длинная статья, но стоит прочитать):
Если предложение WHERE включает несколько выражений, обычно нет производительность, полученная при заказе различные выражения в любом определенный порядок. Это связано с тем, что Оптимизатор запросов SQL Server делает это для вас, экономя ваши усилия. Там являются некоторыми исключениями из этого, что обсуждаются на этом веб-сайте. [7,0, 2000, 2005] Добавлено 1-24-2006
Нет. Оптимизатор решает, какой порядок фильтрует результаты на основе текущей статистики.
Это зависит от СУБД. Сам SQL ничего не говорит о том, как должен выполняться запрос. Это зависит от конкретной реализации.
Если ваша СУБД имела очень упрощенную модель интерпретации запроса последовательно, то сначала положить в поле 1 > 1 в вашем примере (очевидно) было бы быстрее - потому что СУБД сделало бы два прохода, из которых второй проход проходит намного меньше ResultSet.
Если он из той же таблицы, и запрос такой же простой, как и ваш пример, нет, это не имеет значения. По мере того как вы усложняетесь и связываете больше таблиц, он может.