ГДЕ условие как-то избегает полного сканирования таблицы - PullRequest
0 голосов
/ 24 октября 2018

Оценивая производительность при создании запроса представления SQL, я заметил значительное улучшение производительности при добавлении предложения WHERE в конце.Разница в выходных данных невелика (~ 3% меньше строк).

например,

SELECT x,y,z  
FROM (multiple table joins/sub queries)

против

SELECT x,y,z  
FROM (multiple table joins/sub queries)  
WHERE x >= 0 (x is not indexed)

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

РЕДАКТИРОВАТЬ: снимки экрана, показывающие выполнение операции с условием WHERE по сравнению с

enter image description here

enter image description here

1 Ответ

0 голосов
/ 25 октября 2018

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

Когда сталкиваюсь с JOIN(s), оптимизатор часто (но не всегда)) использует эти правила, чтобы решить, с какой таблицы начинать:

  • Начните с таблицы, которая, кажется, имеет лучшую WHERE фильтрацию. может побудить его выбрать стол с x.Даже при полном сканировании таблицы выбор этой таблицы может быть лучше.

  • Начните с самой маленькой таблицы.

Примечание:Сканирует «первую» таблицу;для каждой строки в этой таблице он попадает в «следующую» таблицу, затем в следующую и т. д. Оптимизатор может свободно изменять порядок таблиц по своему усмотрению (в пределах ограничений, таких как LEFT).

В действительности, более поздние воплощения Оптимизатора используют анализ на основе затрат.Однако два вышеприведенных «правила» - вот что эффективно происходит.

Кроме того, Оптимизатор может быть введен в заблуждение статистикой или ее отсутствием, на которой он основывает план запроса.

...