Наскільки детермінованим є створення плану виконання в SQL Server?

З огляду на наступні константи:

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

Враховуючи ці константи, чи буде SQL Server завжди створювати той самий план для заданого запиту?

Якщо ні, чи є інші міркування? Чи слід також враховувати елемент недетермінізму?

sql-server execution-plan determinism

невірно сказати той же план, але ми можемо сказати подібний план. Поряд із зовнішніми чинниками, якими може керувати DBA / Developer; "алгоритми оптимізації плану запитів" та "алгоритми внутрішньої вартості запитів" записуються всередині двигуна сервера SQL. у нас немає такого контролю, щоб усіма способами казати "що вибрати". ми можемо встановити зовнішню обкладку, щоб керувати двигуном для вибору найкращого. для даного запиту, якщо оптимізатор придумав два плани виконання з можливістю сказати різницю у вартості 0,001, то, мабуть, буде неважливо, який план виконання він обрав.

— Ануп Шах

Я не думаю, що ви повинні бути теоретичними щодо цього. Я працював 25 років з різними базами даних, і майже завжди можна переписати запит для кращого виконання. І іноді дуже важко зрозуміти, чому краще з одним способом написання запиту.

Враховуючи ці константи, чи буде SQL Server завжди створювати той самий план для заданого запиту? Якщо ні, чи є інші міркування? Чи слід також враховувати елемент недетермінізму?

Наскільки я знаю, складання запитів є детермінованим. Однією з оригінальних цілей проектування QO було те, що слід було б відтворити плани виконання в іншій системі, використовуючи копію бази даних, що стосується лише статистики . У цьому є кілька тонкощів, навколо параметрів конфігурації, таких як кількість доступної пам'яті та кількість логічних процесорів, але вони охоплені вашим списком речей для синхронізації.

Caveat: Це правда за умови, що слово "той самий" у вашому списку означає , що воно означає у всіх відношеннях абсолютно те саме . Наприклад, "однакові" статистичні дані можуть існувати у двох системах, але вони є абсолютно однаковими, якщо етапи гістограми та інформація про щільність однакові .

Зважаючи на це, процес оптимізації також є надзвичайно складним , тобто може бути важко забезпечити, щоб усі входи до цього детермінованого процесу були однаковими , і що всі внутрішні стани були досить подібними, щоб забезпечити той самий шлях коду через оптимізатор для конкретного складання. Якщо запит містить доступ за межами бази даних (до іншої бази даних чи примірника), ці середовища також повинні бути ідентичними.

Одне, що я хотів би додати до вашого списку, - це перевірити, чи існують будь-які посібники щодо плану у другій базі даних.

Використання недетермінованих функцій, як GETDATE()у запитах, може означати, що ви також отримаєте інший план. Незважаючи на те, що основний оптимізатор не використовує значення безпосередньо, оцінка кардинальності може (див. Постійне складання та оцінка виразів під час оцінки кардинальності ). Я не впевнений, якщо цей клас різниці потрапляє в рамки питання, тому що обидві системи створювали б один і той же план, якщо вони виконуються одночасно (або, загалом, з однаковими вхідними змінними, параметрами та значеннями функцій).

— Пол Білий 9
джерело