Есть ли порядок соединений?

Question

Скажите, что у меня есть запрос, подобный приведенному ниже:

SELECT t1.id, t1.Name
FROM Table1 as t1 --800,000 records
INNER JOIN Table2 as t2 --500,000 records
ON t1.fkID = t2.id
INNER JOIN Table3 as t3 -- 1,000 records
ON t1.OtherId = t3.id

Могу ли я увидеть улучшение производительности, если я изменю порядок своих объединений в таблицах 2 и 3? Смотрите ниже:

SELECT t1.id, t1.Name
FROM Table1 as t1 --800,000 records
INNER JOIN Table3 as t3 -- 1,000 records
ON t1.OtherId = t3.id
INNER JOIN Table2 as t2 --500,000 records
ON t1.fkID = t2.id

Я слышал, что Оптимизатор запросов попытается определить лучший порядок, но не всегда работает. Имеет ли значение версия SQL Server, которую вы используете, имеет значение?

Answer 1

Порядок соединений не имеет значения.

Разница в том, что ваша статистика актуальна.

Один из способов проверить статистику - выполнить запрос в SSMS и включить Фактический план выполнения. Если Расчетное количество строк сильно отличается от Фактического количества строк, используемых какой-либо частью плана выполнения, тогда ваша статистика устарела.

Статистика перестраивается при перестроении связанных индексов. Если позволяет ваше окно обслуживания производства, я буду обновлять статистику каждую ночь.

Это обновит статистику для всех таблиц в базе данных:

exec sp_MSforeachtable "UPDATE STATISTICS ?"

Answer 2

Порядок соединений имеет значение, только если вы укажете OPTION (FORCE ORDER). В противном случае оптимизатор перестроит ваш запрос так, как он сочтет наиболее эффективным.

На самом деле есть определенные случаи, когда я обнаруживаю, что мне нужно использовать FORCE ORDER, но, конечно, они немногочисленны. Если вы не уверены, просто SET STATISTICS [TIME|IO] ON и убедитесь сами. Вероятно, вы обнаружите, что ваша версия работает медленнее, чем оптимизированная, в большинстве, если не во всех случаях.

Answer 3

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

Многое касается статистики, а не количества записей. Например, если подавляющее большинство значений в t1.fkID идентичны, эта информация может сильно повлиять на QO.