Функции интеллектуальной обработки запросов подробно

Область применения: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

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

Рабочие нагрузки можно автоматически сделать подходящими для интеллектуальной обработки запросов, включив для базы данных соответствующий уровень совместимости. Это можно сделать с помощью Transact-SQL. Например, чтобы задать уровень совместимости базы данных sql Server 2022 (16.x):

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

Дополнительные сведения об изменениях, представленных с новыми версиями, см. в следующем разделе:

• Новые возможности SQL Server 2017
• Новые возможности SQL Server 2019
• Новые возможности SQL Server 2022

Адаптивные соединения в пакетном режиме

Область применения: SQL Server (начиная с SQL Server 2017 (14.x)), База данных SQL Azure

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

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

Выполнение с чередованием для MSTVF

Область применения: SQL Server (начиная с SQL Server 2017 (14.x)), База данных SQL Azure

Функция с табличным значением с несколькими операторами (MSTVF) — это тип определяемой пользователем функции, которая может принимать параметры, выполнять несколько инструкций T-SQL и RETURN таблицу.

Перекрестиное выполнение помогает устранить проблемы с производительностью рабочей нагрузки, связанные с фиксированными оценками кратности, связанными с MSTVFs. При выполнении с чередованием используется фактическое количество строк из функции для принятия обоснованного решения о плане запроса.

MSTVFs имеет фиксированное кратность 100 начиная с SQL Server 2014 (12.x) и 1 для более ранних версий SQL Server.

Выполнение с чередованием изменяет однонаправленную границу между этапами оптимизации и выполнения для выполнения с одним запросом и позволяет планам адаптироваться с учетом пересмотренных оценок кратности. Во время оптимизации, если ядро СУБД сталкивается с кандидатом на чередование выполнения, использующего функции с табличным значением нескольких операторов (MSTVFs), оптимизация приостанавливается, выполняет применимые поддеревы, фиксирует точные оценки кратности, а затем возобновляет оптимизацию для подчиненных операций.

На приведенном ниже рисунке изображены выходные данные статистики активных запросов — подмножество общего плана выполнения, показывающее влияние фиксированных оценок кратности из функций MSTVF.

Вы можете сравнить фактическую передачу строк с предполагаемым значением. Следует отметить три области плана (переход справа налево):

• Сканирование таблицы MSTVF имеет фиксированную оценку в 100 строк. Однако в данном примере через это сканирование таблицы MSTVF передается 527 597 строк, как видно в статистике активных запросов — 527597 из 100, то есть фиксированная оценка имеет значительное отклонение.
• Для операции вложенных циклов предполагается, что наружная часть соединения возвращает всего 100 строк. Учитывая, как много строк функция MSTVF возвращает на самом деле, лучше всего перейти на другой алгоритм соединения.
• Для операции хэш-совпадений обратите внимание на небольшой предупреждающий символ, который в данном случае указывает на временную запись на диск.

Сравним предыдущий план с фактическим планом, созданным при включенном выполнении с чередованием:

• Обратите внимание, что сканирование таблицы MSTVF отражает точную оценку кратности. Кроме того, обратите внимание на изменение порядка этой таблицы и другие операции.
• Что касается алгоритмов соединения, мы перешли от операции вложенных циклов Loop к операции хэш-совпадений, которая лучше подходит для такого большого числа строк.
• Также обратите внимание, что прекратились предупреждения о временной записи, так как мы выделяем больше памяти на основе истинного количества строк, поступающих из сканирования таблицы MSTVF.

Допустимые инструкции выполнения с чередованием

Инструкции ссылок MSTVF в выполнении с чередованием сейчас должны быть доступны только для чтения и не входить в состав операции изменения данных. Кроме того, функции MSTVF нельзя выполнять с чередованием, если в них не используются константы времени выполнения.

Преимущества выполнения с чередованием

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

В общем случае выполнение с чередованием оказывается полезным для запросов, где выполняются следующие условия:

• Имеется большое отклонение между предполагаемым и фактическим числом строк для промежуточного результирующего набора (в данном случае — MSTVF).
• Весь запрос чувствителен к изменению размера промежуточного результата. Обычно это происходит, когда над поддеревом в плане запроса имеется сложное дерево. Выполнение с чередованием не принесет никакой выгоды для простой инструкции SELECT * из MSTVF.

Издержки выполнения с чередованием

Издержки должны быть минимальными либо отсутствовать. MSTVFs уже материализованы до внедрения чередуемого выполнения, однако разница заключается в том, что теперь мы разрешаем отложенную оптимизацию и затем используем оценку кратности материализованного набора строк. Как и в случае с любым планом, влияющим на изменения, некоторые планы могут изменяться таким образом, что при улучшенной кратности для поддерева мы получаем ухудшенный план для всего запроса в целом. Устранение рисков может включать отмену уровня совместимости или использование хранилище запросов для принудительной нерегистрируемой версии плана.

Выполнение с чередованием и последовательные выполнения

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

Отслеживание переключаемого действия выполнения

Вы можете просмотреть атрибуты использования в фактическом плане выполнения запроса:

Атрибут плана выполнения	Description
ContainsInterleavedExecutionCandidates	Применяется к узлу QueryPlan. Значение true означает, что план содержит кандидаты на выполнение с чередованием.
IsInterleavedExecuted	Атрибут элемента RuntimeInformation под RelOp для узла TVF. Если значение равно true, значит, операция была материализована как часть операции выполнения с чередованием.

Кроме того, можно отслеживать чередование событий выполнения с помощью следующих расширенных событий:

XEvent	Description
interleaved_exec_status	Это событие возникает, когда происходит выполнение с чередованием.
interleaved_exec_stats_update	Это событие описывает оценки кратности, обновленные выполнением с чередованием.
Interleaved_exec_disabled_reason	Это событие возникает, когда запрос с кандидатом на выполнение с чередованием не получает такое выполнение.

Чтобы разрешить выполнению с чередованием пересматривать оценки кратности MSTVF, нужно выполнить запрос. При этом предполагаемый план выполнения по-прежнему сообщает о наличии кандидатов на выполнение с чередованием с помощью атрибута showplan ContainsInterleavedExecutionCandidates.

Кэширование выполнения с чередованием

Если план удаляется или извлекается из кэша, при выполнении запроса появляется новая компиляция, в которой используется исполнение чередованием. Оператор, использующий создание нового плана с помощью OPTION (RECOMPILE) переключенного выполнения, а не кэша.

Переключение выполнения и взаимодействие хранилище запросов

Планы с использованием выполнения с чередованием можно применять принудительно. План представляет собой версию с оценками кратности, исправленными на основе начального выполнения.

Отключение переключаемого выполнения без изменения уровня совместимости

Выполнение с чередованием можно отключить в области базы данных или инструкции, сохранив уровень совместимости базы данных 140 или более высокий. Чтобы отключить выполнение с чередованием для всех запросов, выполняемых из базы данных, выполните следующую команду в контексте соответствующей базы данных:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

Если этот параметр включен , этот параметр отображается в sys.database_scoped_configurations. Чтобы снова включить выполнение с чередованием для всех запросов, выполняемых из базы данных, выполните следующую команду в контексте соответствующей базы данных:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

Вы также можете отключить выполнение с чередованием для определенного запроса, назначив DISABLE_INTERLEAVED_EXECUTION_TVF в качестве указания запроса USE HINT. Например:

SELECT [fo].[Order Key], [fo].[Quantity], [foo].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession',
                            '1-01-2013',
                            '10-15-2014') AS [foo] ON [fo].[Order Key] = [foo].[Order Key]
                            AND [fo].[City Key] = [foo].[City Key]
                            AND [fo].[Customer Key] = [foo].[Customer Key]
                            AND [fo].[Stock Item Key] = [foo].[Stock Item Key]
                            AND [fo].[Order Date Key] = [foo].[Order Date Key]
                            AND [fo].[Picked Date Key] = [foo].[Picked Date Key]
                            AND [fo].[Salesperson Key] = [foo].[Salesperson Key]
                            AND [fo].[Picker Key] = [foo].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

Указание запроса USE HINT имеет приоритет над конфигурацией базы данных или параметром флага трассировки.

Встраивание скалярных пользовательских функций

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)), База данных SQL Azure

Функция встраивания скалярных определяемых пользователем функций позволяет автоматически преобразовать скалярные определяемые пользовательские функции в реляционные выражения. Затем они внедряются в вызывающий SQL-запрос. Такое преобразование повышает производительность рабочих нагрузок, которые используют скалярные определяемые пользователем функции. Встраивание скалярных определяемых пользователем функций способствует оптимизации с учетом стоимости операций, выполняемых внутри определяемых пользователем функций. Это обеспечивает эффективные планы выполнения с поддержкой наборов и параллелизма вместо неэффективных, итеративных и последовательных планов. Эта функция включена по умолчанию на уровне совместимости базы данных 150 или выше.

Дополнительные сведения см. в разделе Встраивание скалярных функций, определяемых пользователем.

Отложенная компиляция табличных переменных

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)), База данных SQL Azure

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

При отложенной компиляции табличных переменных компиляция инструкции со ссылкой на табличную переменную откладывается до момента первого фактического выполнения инструкции. Это поведение отложенной компиляции совпадает с поведением временных таблиц. Такое изменение позволяет использовать реальную кратность вместо обычного предположения по одной строке.

Чтобы включить отложенную компиляцию табличных переменных, включите уровень совместимости базы данных 150 или выше для базы данных, к которой вы подключаетесь при выполнении запроса.

При отложенной компиляции табличных переменных другие характеристики табличных переменных не изменяются. Например, в табличные переменные не добавляется статистика по столбцам.

Также при использовании этой функции не повышается частота перекомпиляции. Эта функция эффективна при начальной компиляции. Итоговый кэшированный план создается на основе числа строк табличных переменных начальной отложенной компиляции. Кэшированный план повторно используется последующими запросами до тех пор, пока план не будет исключен или перекомпилирован.

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

Отключение отложенной компиляции табличной переменной без изменения уровня совместимости

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

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Чтобы повторно включить отложенную компиляцию табличной переменной для всех запросов, поступающих из базы данных, выполните следующий пример в контексте соответствующей базы данных:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Вы также можете отключить отложенную компиляцию табличной переменной для определенного запроса, назначив DISABLE_DEFERRED_COMPILATION_TV в качестве указания запроса USE HINT. Например:

DECLARE @LINEITEMS TABLE 
    (L_OrderKey INT NOT NULL,
     L_Quantity INT NOT NULL
    );

INSERT @LINEITEMS
SELECT L_OrderKey, L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
    O_CustKey,
    O_OrderStatus,
    L_QUANTITY
FROM    
    ORDERS,
    @LINEITEMS
WHERE    O_ORDERKEY    =    L_ORDERKEY
    AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

Оптимизация планов с учетом параметров

Область применения: SQL Server 2022 (16.x) База данных SQL Azure Управляемый экземпляр SQL Azure

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

• Дополнительные сведения об оптимизации PSP см. в разделе "Оптимизация конфиденциального плана параметров".
• Дополнительные сведения о параметризации и конфиденциальности параметров см. в разделе "Конфиденциальность параметров" и "Параметры" и "Повторное использование плана выполнения".

Приблизительная обработка запросов

Приблизительная обработка запросов — это новое семейство функций. Оно позволяет агрегировать большие наборы данных, для которых скорость реагирования намного важнее абсолютной точности. Пример вычисляет COUNT(DISTINCT()) 10 миллиардов строк для отображения на панели мониторинга. Абсолютная точность здесь не требуется, но критически важна скорость реагирования.

Приблизительный подсчет различных объектов

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)), База данных SQL Azure

Новая агрегатная функция APPROX_COUNT_DISTINCT возвращает приблизительное количество содержащихся в группе уникальных значений, не равных NULL.

Эта функция доступна начиная с SQL Server 2019 (15.x), независимо от уровня совместимости.

Дополнительные сведения см. в описании APPROX_COUNT_DISTINCT (Transact-SQL).

Приблизительный процентиль

Область применения: SQL Server (начиная с SQL Server 2022 (16.x)), База данных SQL Azure

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

Дополнительные сведения см. в статьях APPROX_PERCENTILE_DISC (Transact-SQL) и APPROX_PERCENTILE_CONT (Transact-SQL)

Пакетный режим для данных rowstore

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)), База данных SQL Azure

Пакетный режим для данных rowstore обеспечивает выполнение в пакетном режиме для аналитических рабочих нагрузок без необходимости использовать индексы columnstore. Эта функция поддерживает выполнение в пакетном режиме и фильтры по битовым картам для кучи на диске и индексов сбалансированного дерева. Пакетный режим rowstore обеспечивает поддержку для всех операторов, доступных в этом режиме.

Примечание.

В документации термин B-tree обычно используется в ссылке на индексы. В индексах rowstore ядро СУБД реализует дерево B+. Это не относится к индексам columnstore или индексам в таблицах, оптимизированных для памяти. Дополнительные сведения см. в руководстве по архитектуре и проектированию индексов SQL Sql Server и Azure.

Общие сведения о выполнении в пакетном режиме

В SQL Server 2012 (11.x) появилась новая функция для ускорения аналитических рабочих нагрузок: индексов columnstore. Варианты использования и производительность индексов columnstore увеличились в каждом последующем выпуске SQL Server. Создание индексов columnstore в таблицах может повысить производительность аналитических рабочих нагрузок. Но на самом деле здесь применяются два связанных, но различных набора технологий.

• Индексы columnstore позволяют аналитическим запросам получать доступ к данным только в требуемых столбцах. Кроме того, сжатие в формате columnstore намного эффективнее, чем для традиционных индексов rowstore.
• При обработке в пакетном режиме операторы запросов выполняются более эффективно. Они работают по пакету строк, а не по одной строке за раз. Многие другие улучшения масштабируемости связаны с обработкой пакетного режима. Дополнительные сведения о пакетном режиме см. в разделе Режимы выполнения.

Эти два набора функций взаимодействуют, чтобы оптимизировать скорость выполнения операций ввода-вывода и использование ЦП.

• Благодаря индексам columnstore в памяти помещается больше данных. Это снижает нагрузку на подсистему ввода-вывода.
• При обработке в пакетном режиме ресурсы ЦП используются более эффективно.

Эти две технологии совместно используются везде, где это возможно, для получения дополнительных преимуществ. Например, статические выражения в пакетном режиме можно вычислить в рамках сканирования индекса columnstore. Кроме того, с помощью соединений и статических вычислений пакетного режима гораздо более эффективно обрабатываются данные columnstore, которые сжаты с использованием кодирования по длине серий.

Но важно понимать, что эти две функции не зависят друг от друга.

• Можно создать план со строковым режимом, который использует индексы columnstore.
• Можно создать план с пакетным режимом, который использует только индексы rowstore.

Но обычно совместное использование этих компонентов дает наилучший результат. Перед SQL Server 2019 (15.x) оптимизатор запросов SQL Server считался пакетным режимом обработки только для запросов, включающих по крайней мере одну таблицу с индексом columnstore.

Индексы Columnstore могут не подходить для некоторых приложений. Приложение может использовать другие функции, которые не совместимы с индексами columnstore. Например, изменения на месте не совместимы со сжатием columnstore. Поэтому таблицы с кластеризованными индексами columnstore не поддерживают триггеры. Что еще важнее, индексы columnstore повышают затраты на выполнение инструкций DELETE и UPDATE.

Для некоторых гибридных транзакционно-аналитических рабочих нагрузок издержки на транзакционную нагрузку перевешивают преимущества от использования индексов columnstore. В таких сценариях можно улучшить использование ЦП, применяя исключительно режим пакетной обработки. Поэтому функция "Пакетный режим для данных rowstore" позволяет применять пакетный режим для всех запросов независимо от типа используемых индексов.

Рабочие нагрузки, для которых целесообразно использовать пакетный режима для данных rowstore

Пакетный режим для данных rowstore предоставляет преимущества для рабочих нагрузок со следующими характеристиками:

• Если значительная часть рабочей нагрузки состоит из аналитических запросов. Обычно такие запросы используют соединения или статистические выражения для обработки сотен тысяч строк или даже больше.
• Если рабочая нагрузка сильно зависит от ЦП. Для всех случаев, когда узким местом остается скорость ввода и вывода, рекомендуется при любой возможности применять индекс columnstore.
• Если создание индекса columnstore сопряжено со слишком большими транзакционными расходами для рабочей нагрузки. Возможно также, что индекс columnstore создать нельзя из-за зависимости приложения от функции, которая пока не поддерживает работу с индексами columnstore.

Примечание.

Использование пакетного режима для данных rowstore помогает только сократить потребление ресурсов ЦП. Если же узким местом являются операции ввода-вывода и данные не кэшируются ("холодный" кэш), использование пакетного режима для rowstore не сократит время, затраченное на выполнение запроса. Аналогичным образом, если на компьютере не хватает памяти для кэширования всех данных, повышение производительности маловероятно.

Что изменяется при использовании пакетного режима для данных rowstore?

Пакетный режим в rowstore требует наличия базы данных на уровне совместимости 150.

Даже если запрос не обращается к таблицам с индексами columnstore, обработчик запросов использует эвристики, чтобы решить, следует ли рассматривать пакетный режим. Этот эвристический анализ включает следующее:

1. Первоначальной проверки размеров таблиц, используемых операторов и предполагаемого количества элементов во входном запросе.
2. Дополнительных проверок, так как оптимизатор обнаруживает новые, более дешевые планы для запроса. Если эти альтернативные планы используют пакетный режим незначительно, оптимизатор прекратит изучение альтернатив с пакетным режимом.

Если для данных rowstore используется пакетный режим, фактический режим выполнения будет обозначен как batch mode (пакетный режим) в плане запроса. Оператор сканирования использует пакетный режим для кучи на диске и индексов сбалансированного дерева. При этом сканировании пакетного режима можно оценить фильтры растрового изображения в пакетном режиме. Вы можете заметить в плане и другие операторы пакетного режима. Например, хэш-соединения, статические операции на основе хэша, сортировки, статистические операции с окнами, фильтры, объединение и операторы вычисления скалярного значения.

Замечания

Планы запросов не всегда используют пакетный режим. Оптимизатор запросов может определить, что пакетный режим не улучшит обработку запроса.

Пространство поиска оптимизатора запросов изменяется. Например, план в строковом режиме может не совпадать с планом, который вы получите на более низком уровне совместимости. А план в пакетном режиме может не совпадать с планом, который вы получите для индекса columnstore.

Новый режим сканирования пакетного режима для данных rowstore может изменять планы для запросов, в которых сочетаются индексы columnstore и rowstore.

Для нового сканирования пакетного режима для данных rowstore действует ряд ограничений:

• Сканирование не будет использоваться для таблиц OLTP, выполняющейся в памяти, или для любых других индексов, отличных от индексов в виде куч на диске и сбалансированных деревьев.
• Также оно не применяется, если LOB-столбец извлекается или фильтруется. Это ограничение относится и к наборам разреженных столбцов и XML-столбцам.

Есть запросы, для которых пакетный режим не применяется даже с индексами columnstore. В качестве примера можно назвать запросы с курсорами. Эти исключения относятся и к пакетному режиму для индексов rowstore.

Настройка пакетного режима для данных rowstore

Конфигурация BATCH_MODE_ON_ROWSTORE с областью базы данных по умолчанию включена.

Вы можете отключить пакетный режим в rowstore, не изменив уровень совместимости базы данных:

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

Пакетный режим можно отключить в rowstore с помощью конфигурации с областью базы данных. Но вы по-прежнему можете переопределить параметр на уровне запроса с помощью ALLOW_BATCH_MODE указания запроса. В следующем примере пакетный режим для данных rowstore включается, несмотря на то что функция отключена через конфигурацию на уровне базы данных:

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

Вы также можете отключить пакетный режим в хранилище строк для определенного запроса с помощью DISALLOW_BATCH_MODE указания запроса. См. следующий пример.

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

Функции обратной связи по обработке запросов

Функции обратной связи по обработке запросов являются частью семейства функций интеллектуальной обработки запросов.

Обратная связь по обработке запросов — это процесс, с помощью которого обработчик запросов в SQL Server, База данных SQL Azure и Управляемый экземпляр SQL Azure использует исторические данные о выполнении запроса, чтобы решить, может ли запрос получить помощь от одного или нескольких изменений в том, как он компилируется и выполняется. Данные о производительности собираются в хранилище запросов с различными предложениями по улучшению выполнения запросов. При успешном выполнении эти изменения сохраняются на диске в памяти и (или) в хранилище запросов для дальнейшего использования. Если предложения не дают достаточного улучшения, они удаляются, и запрос продолжает выполняться без этой обратной связи.

Сведения о возможностях обработки запросов, доступных в разных выпусках SQL Server или в База данных SQL Azure или Управляемый экземпляр SQL Azure, см. в статьях "Интеллектуальная обработка запросов" в базах данных SQL или в следующих статьях для каждой функции обратной связи.

Обратная связь для временно предоставляемого буфера памяти

Отзывы о предоставлении памяти появились в волнах за последние основные выпуски SQL Server.

Обратная связь по временно предоставляемому буферу памяти в пакетном режиме

Сведения о предоставлении отзывов о предоставлении памяти в пакетном режиме см . в отзыве о предоставлении памяти в режиме пакетной службы.

Обратная связь по временно предоставляемому буферу памяти в строковом режиме

Сведения о предоставлении отзывов о предоставлении памяти в режиме строк см . в отзыве о предоставлении памяти в режиме строк.

Обратная связь для временно предоставляемого буфера памяти в режиме процентиля и сохраняемости

Сведения о предоставлении отзывов о предоставлении памяти в режиме процента и сохраняемости см . в отзыве о предоставлении памяти в режиме процента и сохраняемости.

Обратная связь по степени параллелизма (DOP)

Дополнительные сведения о обратной связи DOP см . в статье о степени параллелизма (DOP).

Оценка кратности (CE) отзывы

Дополнительные сведения о отзывах CE см . в отзыве о оценке кратности (CE).

Принудительное применение оптимизированного плана с помощью хранилища запросов

Сведения об оптимизированной настройке плана принудив хранилище запросов, посетите оптимизированный план принудив хранилище запросов.

Связанный контент

• Соединения (SQL Server)
• Режимы выполнения
• Руководство по архитектуре обработки запросов
• Справочник по логическим и физическим операторам Showplan
• ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
• Новые возможности SQL Server 2017
• Новые возможности SQL Server 2019
• Новые возможности SQL Server 2022
• Демонстрация интеллектуальной обработки запросов
• Свертывание констант и вычисление выражений
• Интеллектуальные демонстрации обработки запросов на GitHub
• Центр производительности для базы данных SQL Azure и ядра СУБД SQL Server
• Мониторинг производительности с использованием хранилища запросов
• Рекомендации по мониторингу рабочих нагрузок с помощью хранилище запросов