Якщо екземпляр MAXDOP
встановлений у 1, а підказки запитів використовуються для того, щоб конкретні запити йшли паралельно, чи все-таки використовується значення порогу вартості для паралельності SQL для того, щоб вирішити, чи дійсно йти паралельно чи ні?
Проста відповідь: так .
Деталі
Тут відбувається кілька окремих речей, які важливо розділити:
Який ефективний максимальний ступінь паралелізму доступний для запиту?
Сприяють цьому: (в основному, за важливістю):
MAX_DOP
Налаштування ресурсу губернатора
MAXDOP
Налаштування підказки запиту
- Параметр
max degree of parallelism
конфігурації примірника
Деталі пояснюються в налаштуваннях сервера "Максимальна ступінь паралельності", MAX_DOP губернатора ресурсу та підказці MAXDOP на запит - який слід використовувати SQL Server? Джек Лі, старший інженер ескалації для обслуговування клієнтів та підтримки Microsoft SQL Server. Таблиця нижче відтворена із цього посилання:
Чи буде план запитів використовувати паралелізм?
Оптимізатор запитів SQL Server завжди спочатку знаходить послідовний план *.
Тоді, якщо:
- Подальша оптимізація виправдана; і
- Вартість найкращого послідовного плану перевищує
cost threshold for parallelism
значення конфігурації
... оптимізатор спробує знайти паралельний план.
Тоді, якщо:
- Знайдено паралельний план (тобто можливий); і
- Вартість паралельного плану менша, ніж найкращий серійний план
... буде виготовлений паралельний план.
Примітка:cost threshold for parallelism
тільки впливає оптимізатор виглядає для паралельного плану. Після кешування паралельного плану він виконуватиметься з використанням паралелізму при його повторному використанні (доки доступні потоки) незалежно від налаштування CTFP.
Приклади
В обох прикладах, наприклад, екземпляр maxdop 1 та підказка запиту maxdop 2, ефективний доступний DOP становить 2. Якщо обраний паралельний план, він використовуватиме DOP 2.
Приклад 1
З огляду на CTFP 50 і найдешевший серійний план, який виявився вартістю 30, SQL Server не намагатиметься знайти паралельний план. Буде вироблений серійний план.
Приклад 2
З огляду на CTFP 50 і найдешевший серійний план, який виявився вартістю 70, SQL Server спробує знайти паралельний план. Якщо у цього плану (якщо його знайдеться) вартість менше 70 (вартість послідовного плану), то буде виготовлений паралельний план.
Кінцевим результатом оптимізації запитів є завжди один кешований план: послідовний або паралельний. Оптимізатор знаходить лише послідовний план у фазах пошуку0 (TP) та search1 (QP).
Потім може (як описано) повторно запустити пошук1 з вимогою створити паралельний план. Тоді робиться вибір між послідовними та паралельними, виходячи з найкращої досі вартості плану. Цей вибір є обов'язковим у випадку, якщо оптимізація перейде до пошуку2 (Повна оптимізація). Кожна фаза оптимізації розглядає безліч альтернатив, але вихід зі стадії завжди є найкращим планом, який є або послідовним, або паралельним.
Про щось із цього я писав у Myth: SQL Server кешує послідовний план з кожним паралельним планом