Підказки в запитах (transact-sql)

Підказки в запиті вказують, що для запиту повинна використовуватися задана підказка. Підказки в запиті впливають на всі оператори в інструкції. Якщо в основному запиті використовується операція UNION, тільки останній запит, який використовує її, може містити пропозицію OPTION. Підказки в запиті вказуються як частина пропозиції OPTION. Якщо оптимізатор запитів не формує допустимий план через одну або кількох підказок в запиті, виникає помилка 8622.

Оскільки оптимізатор запитів SQL Server зазвичай вибирає найкращий план виконання запиту, використовувати підказки рекомендується тільки досвідченим розробникам і адміністраторам баз даних в самому крайньому випадку.

Вказує, що агрегати в пропозиціях GROUP BY, DISTINCT і COMPUTE запиту повинні використовувати хешування або упорядкування.

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

Вказує, що всі операції з'єднання в усьому запиті виконуються за допомогою рекомендацій LOOP JOIN, MERGE JOIN або HASH JOIN. Якщо вказано більше однієї підказки з'єднання, оптимізатор запитів вибирає найменш витратну стратегію з допустимих.

Якщо в одному запиті підказка з'єднання вказана для певної пари таблиць в реченні FROM, вона має пріоритет в з'єднанні двох таблиць, хоча також слід враховувати підказки в запиті. Таким чином, підказка в з'єднанні для пари таблиць може тільки обмежувати вибір допустимих методів з'єднання для підказки в запиті. Додаткові відомості див. У розділі Підказки в з'єднанні (Transact-SQL).

Вказує, що запит оптимізований для швидкого отримання перших number_rows. рядків. Воно повинно бути невід'ємним цілим числом. Після повернення перших number_rows рядків запит залишиться активним і повертає повний результуючий набір.

Вказує, що при оптимізації запиту зберігається порядок об'єднання, заданий синтаксисом запиту. Використання підказки FORCE ORDER не впливає на можливий реверс ролей в оптимізаторі запитів. Додаткові відомості див. У розділі Основні відомості про хеш-судинних.

Інструкція MERGE отримує доступ спочатку до вихідної таблиці, потім до цільової в порядку з'єднання, прийнятому за замовчуванням, якщо не задано пропозицію WHEN SOURCE NOT MATCHED. Якщо вказати FORCE ORDER, зберігається поведінка за умовчанням.

Відомості про те, як оптимізатор запитів SQL Server примусово використовує підказку FORCE ORDER, якщо запит містить уявлення, див. Розділ Дозвіл уявлень.

Перевизначає параметр конфігурації max degree of parallelismsp_configure і регулятор ресурсів для запиту, уточнюючого цей параметр. Підказка в запиті MAXDOP може перевищити значення, задане за допомогою процедури sp_configure. Якщо MAXDOP перевищує значення, налаштоване за допомогою регулятора ресурсів, компонент Database Engine використовує значення MAXDOP регулятора ресурсів, описане в ALTER WORKLOAD GROUP (Transact-SQL). Всі семантичні правила, використовувані параметром конфігурації max degree of parallelism, застосовні при використанні підказки у запиті MAXDOP. Додаткові відомості див. У розділі Параметр max degree of parallelism.

Якщо значення MAXDOP дорівнює нулю, то сервер вибирає максимальну ступінь паралелізму. Сервер створює внутрішнє обмеження DOP на рівні 64.

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

Ім'я локальної змінної, використовуваної в запиті, якою може бути присвоєно значення для використання з підказкою в запиті OPTIMIZE FOR.

Вказує, що оптимізатор запитів використовує статистичні дані замість початкового значення, щоб визначити значення локальної змінної при оптимізації запиту.

Символьна константа, значення якої присвоюється аргументу @variable_name для використання в підказці в запиті OPTIMIZE FOR. Значення literal_constant використовується тільки в процесі оптимізації запиту, а не в якості значення @variable_name в процесі виконання запиту. Значення literal_constant може бути будь-яким системним типом даних SQL Server, який може бути виражений як символьна константа. Тип даних значення literal_constant повинен неявно наводитися до типу даних, на який посилається аргумент @variable_name в запиті.

Підказка OPTIMIZE FOR може використовуватися для скасування ухвали параметрів за замовчуванням в оптимізаторі або при створенні структури плану. Додаткові відомості див. У розділах Перекомпіляція збережених процедур і Оптимізація запитів в використовуваних додатках за допомогою структур планів.

OPTIMIZE FOR UNKNOWN

Якщо запит скомпільовано і оптимізований, наказує оптимізатора запитів використовувати статистичні дані замість початкових значень для всіх локальних змінних, включаючи параметри, створені з примусовою параметризацією. Додаткові відомості про примусову параметризації см. В розділі Примусова параметризация.

Якщо підказки OPTIMIZE FOR @variable_name = literal_constant і OPTIMIZE FOR UNKNOWN використовуються в підказці в одному запиті, оптимізатор запитів буде використовувати аргумент literal_constant. вказаний для конкретного значення, і UNKNOWN - для решти значень змінних. Значення використовуються тільки в процесі оптимізації запиту, але не в процесі виконання.

Вказує правила параметризації SQL Server, які оптимізатор запитів застосовує до запиту при його компіляції.

Підказка в запиті PARAMETERIZATION може бути вказана тільки всередині структури плану. Вона не може бути визначена безпосередньо в запиті.

Значення SIMPLE дає оптимізатора запитів вказівку використовувати просту параметризацію. Значення FORCED дає оптимізатора запитів рекомендацію використовувати примусову параметризацію. Підказка в запиті PARAMETERIZATION використовується для перевизначення поточних налаштувань параметра PARAMETERIZATION в структурі плану бази даних. Додаткові відомості див. У розділі Вказівка ​​механізму параметризації запитів за допомогою структур плану.

Вказує компоненту SQL Server Database Engine відкинути план, сформований після виконання запиту, змушуючи оптимізатор запитів перекомпіліровать план запиту під час наступного виконанні цього запиту. Без вказівки підказки RECOMPILE компонент Database Engine кешируєт плани запитів і використовує їх повторно. При компіляції планів запиту підказка в запиті RECOMPILE використовує поточні значення всіх локальних змінних в запиті і, якщо запит знаходиться всередині процедури, що, поточні значення для всіх параметрів.

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

Змушує оптимізатор запитів використовувати план, який працює з рядками найбільшого потенційного розміру, можливо, з втратою продуктивності. При обробці запиту проміжним таблицями і операторам може знадобитися зберігати і обробляти рядки, які ширше, ніж будь-які з вхідних рядків. Рядки можуть бути настільки широкі, що іноді деякі оператори не зможуть їх обробити. Коли це відбувається, компонент Database Engine повертає помилку при виконанні запиту. За допомогою підказки ROBUST PLAN оптимізатора запитів дається вказівка ​​не вибирати жоден з планів запитів, який може викликати проблему.

Якщо такий план неможливий, оптимізатор запитів повертає помилку відразу, не відкладаючи виявлення помилок на момент виконання запиту. Рядки можуть містити стовпці змінної довжини; компонент Database Engine дозволяє вказати для рядків максимальний потенційний розмір, при перевищенні якого компонент Database Engine може не зуміти обробити їх. В основному, незважаючи на максимальний потенційний розмір, програма зберігає рядки, які мають актуальні розміри з обмеженнями, які компонент Database Engine може обробити. Якщо компонент Database Engine зустрічає занадто довгий рядок, повертається помилка виконання.

Змушує оптимізатор запитів знизити приблизний поріг повторної компіляції для запиту. Передбачуване порогове значення повторної компіляції - це точка, в якій запит автоматично перекомпілюється, якщо в таблиці при виконанні інструкцій UPDATE, DELETE або INSERT змінилося очікувана кількість індексованих стовпців. Вказуючи підказку KEEP PLAN, переконайтеся, що запит не буде часто перекомпіліровать при виконанні множинних оновлень в таблиці.

Примушує оптимізатор запитом не перекомпіліровать запит при зміні статистики. Вказуючи підказку KEEPFIXED PLAN, переконайтеся, що запит буде перекомпілювати тільки при зміні схеми базових таблиць або якщо по відношенню до них виконана процедура sp_recompile.

Вказує, що виконується розгортання індексованих уявлень, і оптимізатор запитом не буде розглядати індексовані уявлення як заміну будь-яких частин запиту. Подання розгортається при заміні імені уявлення на визначення уявлення в тексті запиту.

Ця підказка в запиті віртуально забороняє пряме використання індексованих уявлень і індексів для індексованих уявлень в плані запиту.

Дії цієї підказки схильні тільки уявлення в частині SELECT інструкцій, включаючи що знаходяться в інструкціях INSERT, UPDATEMERGE і DELETE.

Вказує максимально допустиме кількість рекурсій для запиту. Число number - невід'ємне ціле, що перебуває в діапазоні між 0 і 32 767. При вказівці 0 не застосовується ніякого обмеження. Якщо цей параметр не вказано, обмеження за замовчуванням дорівнює 100.

Якщо в процесі виконання запиту досягнуте вказане число або число за замовчуванням для підказки MAXRECURSION, виконання запиту завершується і повертається помилка.

Через цю помилку всі дії інструкції відкочуються. Якщо це інструкція SELECT, може бути повернута частина результатів або не повернуто нічого. Будь-які повернуті часткові результати можуть не включати всіх рядків на рекурсивних рівнях, розташованих за вказаними максимальним рівнем рекурсії.

Примушує оптимізатор запитів використовувати існуючий план запиту для запиту, визначеного параметром 'xml_plan'. Додаткові відомості див. У розділі Вказівка ​​планів запитів за допомогою форсування плану. Підказку USE PLAN не можна вказувати в інструкціях INSERT, UPDATE MERGE і DELETE.

Застосовує задану табличну підказку до таблиці або поданням, відповідному аргументу exposed_object_name. Табличні підказки рекомендується використовувати в якості підказок в запитах тільки в контексті структури плану.

Аргумент exposed_object_name може представляти одну з наступних посилань.

Якщо в реченні FROM запиту використовується псевдонім таблиці або подання, цим псевдонімом є exposed_object_name.

Якщо аргумент exposed_object_name заданий без вказівки табличній підказки, всі індекси, задані в запиті як частина табличній підказки, не враховуються, а використання індексів визначається оптимізатором запиту. Цей метод можна використовувати для усунення впливу табличній підказки INDEX, якщо неможливо змінити початковий запит. Див. Приклад К.

Таблична підказка, що застосовується в якості підказки в запиті до таблиці або поданням, яке відповідає аргументу exposed_object_name. Опис цих підказок см. В розділі Табличні підказки (Transact-SQL).

Табличні підказки, за винятком INDEX і FORCESEEK, не допускаються в якості підказок в запитах, крім тих випадків, коли в запиті вже міститься пропозиція WITH, що задає табличную підказку. Додаткові відомості див. Нижче, в розділі «Примітки».

Підказки в запиті не можна вказувати в інструкції INSERT, крім випадку, коли всередині інструкції використовується пропозицію SELECT.

Підказки в запиті можна вказувати тільки в запитах верхнього рівня, але не у вкладених запитах. Якщо табличная підказка задана в якості підказки в запиті, її можна вказати в запиті верхнього рівня або у вкладеному запиті. Проте, значення аргументу exposed_object_name в реченні TABLE HINT має точно відповідати видимому імені в запиті або вкладеному запиті.

Визначення табличних підказок як підказок в запиті

Табличну підказку INDEX або FORCESEEK рекомендується використовувати в якості підказки в запиті тільки в контексті структури плану. Структури планів корисні, якщо не можна змінити початковий запит, наприклад тому, що він є додатком стороннього розробника. Підказки в запиті, задані в структурі планів, додаються до запиту перед його компіляцією і оптимізацією. У нерегламентованих запитах пропозицію TABLE HINT використовується тільки при тестуванні інструкцій структури планів. Для всіх інших нерегламентованих запитів рекомендується вказувати ці підказки тільки як табличні.

Табличні підказки INDEX і FORCESEEK, зазначені в якості підказки в запиті, допустимі для наступних об'єктів:

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

Динамічні адміністративні уявлення

Іменовані вкладені запити

Табличні підказки INDEX і FORCESEEK можуть бути вказані як підказки в запитах для запиту, який не має існуючих табличних підказок. Крім того, ними можна замінити існуючі підказки INDEX або FORCESEEK в цьому запиті, відповідно. Табличні підказки, за винятком INDEX і FORCESEEK, не допускаються в якості підказок в запитах, крім тих випадків, коли в запиті вже міститься пропозиція WITH, що задає табличную підказку. У цьому випадку, щоб зберегти семантику запиту, необхідно також вказати відповідну табличну підказку як підказка в запиті, задавши в реченні OPTION ключове слово TABLE HINT. Наприклад, якщо запит містить табличну підказку NOLOCK, то пропозиція OPTION в параметрі @hints структури плану також має містити підказку NOLOCK. Див. Приклад Л. Якщо вказати табличную підказку, відмінну від INDEX або FORCESEEK, з використанням TABLE HINT в реченні OPTION без збігається підказки в запиті (або навпаки), буде повернуто помилку 8702, показує, що пропозиція OPTION може викликати зміну в семантиці запиту, і запит завершиться з помилкою. Додаткові відомості див. У розділі Використання посібника в запитах INDEX і FORCESEEK в структурах планів.