Чи можна надати оптимізатору більше або весь час, який йому потрібен?


18

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

Мені було цікаво, чи можна це відмінити, щоб ви могли давати оптимізатору весь час потреби (або певну кількість мілісекунд).

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

Звичайно, у вас є щільна петля, вам слід переписати запит, щоб він пройшов, але потерпіть мене.

Це більше питання з цікавості, а також перевірити, чи є іноді різниця між оптимізацією короткого замикання та повною.

Виявляється, ви можете приділити оптимізатору більше часу з прапором слідів 2301. Це не зовсім те, що я просив, але він наближається.

Найкраща інформація, яку я знайшла з цього приводу, - це розширення моделювання запитів процесорів у SQL Server 2005 SP1 Ian Jose.

Використовуйте цей слід прапор обережно! Але це може бути корисно, коли придумують кращі плани. Дивись також:

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

Відповіді:


16

Поруч із простеженням прапора 2301, є 8780, який дійсно робить оптимізатор «більш важким», оскільки він просто надає йому більше часу (не необмеженого, як детально описано тут (російська) та менш детально тут ), щоб зробити свою справу.

Детальний опис англійською мовою оригінального автора російської статті. яке включає власне попередження автора:

не рекомендується ніколи використовувати його у виробництві .

Поєднання двох і застосування їх (дуже вибірково за допомогою підказки ЗАПРОШЕННЯ (QUERYTRACEON 2301, QUERYTRACEON 8780) до запиту 4-рівневих вкладених вбудованих TVF (де тільки той, що знаходиться внизу, буде робити будь-яку реальну роботу, а верхній рівень буде співвідносити результати за допомогою підпитів EXISTS) призвели до приємного ПРИЄДНАННЯ та декількох ЛЕГИХ ШПУЛЬ, які скоротили час виконання наполовину.


4

Ні, ти не можеш.

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

Наприклад, ви хочете дізнатися, коли запит починає масштабуватись менш ефективно, ніж O (n), коли об'єм даних + розподіл даних змінюється: надання більше часу оптимізатору не додає тут значення.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.