Насколько детерминистическим является создание плана выполнения в SQL Server?

Даны следующие константы:

Одна и та же база данных с одинаковой структурой (таблицы, индексы и т. Д.)
Одни и те же данные
Та же SQL Server и аппаратная конфигурация
Та же статистика
Те же параметры SET в клиенте
Те же версии SQL Server
Те же флаги трассировки

Учитывая эти константы, SQL Server всегда будет производить один и тот же план для данного запроса?

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

sql-server execution-plan determinism

будет неверно говорить тот же план, но мы можем сказать, что аналогичный план. Наряду с внешними факторами, которые DBA / Developer могут контролировать; «Алгоритмы оптимизации плана запросов» и «Алгоритмы стоимости внутренних запросов» написаны внутри механизма SQL-сервера. мы не можем контролировать «что выбрать» во всех отношениях. мы можем установить внешний env, чтобы направлять двигатель, чтобы выбрать лучший. для данного запроса, если оптимизатор разработал два плана выполнения, скажем, с разницей в 0,001 стоимости, то, я думаю, будет неважно, какой план выполнения он выберет.

— Ануп Шах

Я не думаю, что вы должны быть теоретически об этом. Я 25 лет работал с разными базами данных, и почти всегда можно переписать запрос для лучшего выполнения. И иногда очень трудно понять, почему лучше с одним способом написания запроса.

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

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

Предостережение: Это правда, если слово «один и тот же» в вашем списке будет означать одно и то же во всех отношениях . Например, «одинаковые» статистические данные могут существовать в двух системах, но они абсолютно одинаковы, если шаги гистограммы и информация о плотности идентичны .

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

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

Использование недетерминированных функций, таких как GETDATE()запросы, может также означать, что вы получаете другой план. Хотя основной оптимизатор не использует это значение напрямую, оценка мощности может (см. Сгибание констант и оценка выражений во время оценки мощности ). Я не уверен, попадает ли этот класс различий в рамки вопроса, потому что обе системы выдают один и тот же план, если выполняются в одно и то же время (или, в более общем случае, с одинаковыми входными переменными, параметрами и значениями функций).

— Пол Уайт 9
источник