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

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

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

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

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

Все функции IQP доступны в Управляемый экземпляр SQL Azure и Azure SQL базах данных, иногда в зависимости от режима совместимости каждой базы данных. Дополнительные сведения об изменениях, внесенных в новые версии, см. в разделе:

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

Применимо к: SQL Server (начиная сSQL Server 2017 (14.x);), База данных SQL Azure

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

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

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

Применимо к: SQL Server (начиная сSQL Server 2017 (14.x);), База данных SQL Azure

При выполнении с чередованием используется фактическое количество строк из функции для принятия обоснованного решения о плане запроса. См. дополнительные сведения о функциях с табличным значением с несколькими инструкциями (MSTVF).

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

Функции MSTVF имеют фиксированное предполагаемое значение кратности 100 начиная с SQL Server 2014 (12.x) и 1 в более ранних версиях SQL Server. Выполнение с чередованием помогает устранить проблемы с производительностью рабочих нагрузок, вызванные фиксированными оценками кратности, которые связаны с функциями MSTVF. Дополнительные сведения о функциях MSTVF см. в разделе Создание определяемых пользователем функций (ядро СУБД).

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

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

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

Изображение потока строк плана выполнения и предполагаемых строк.

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

Рисунок плана выполнения с чередованием.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

xEvent Описание
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 (начиная с SQL Server 2022 (16.x))

Оптимизация планов с учетом параметров (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)), база данных Azure SQL

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

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

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

Применимо к: SQL Server (начиная сSQL Server 2019 (15.x)), База данных SQL Azure

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

Примечание

В документации по SQL Server термин "сбалансированное дерево" обычно используется в отношении индексов. В индексах rowstore SQL Server реализует B+-дерево. Это не относится к индексам columnstore или хранилищам данных в памяти. Дополнительные сведения см. в руководстве по архитектуре и разработке индексов SQL Server.

Историческая справка

В 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 (пакетный режим) в плане запроса. Оператор сканирования использует пакетный режим для кучи на диске и индексов сбалансированного дерева. При этом сканировании пакетного режима можно оценить фильтры растрового изображения в пакетном режиме. Вы можете заметить в плане и другие операторы пакетного режима. Например, хэш-соединения, статические операции на основе хэша, сортировки, статистические операции с окнами, фильтры, объединение и операторы вычисления скалярного значения.

Remarks

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

Пространство поиска оптимизатора запросов изменяется. Например, план в строковом режиме может не совпадать с планом, который вы получите на более низком уровне совместимости. А план в пакетном режиме может не совпадать с планом, который вы получите для индекса 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'));

Вы также можете отключить пакетный режим в rowstore для определенного запроса с помощью 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'));

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также раздел

Дальнейшие действия