Поделиться через

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

Применимо к:SQL ServerAzure SQL База данныхAzure SQL Управляемый экземплярSQL База данных в Microsoft Fabric

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

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

ALTER DATABASE [WideWorldImportersDW]
    SET COMPATIBILITY_LEVEL = 160;

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

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

Область применения: 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 в выполнении с чередованием сейчас должны быть доступны только для чтения и не входить в состав операции изменения данных. Кроме того, MSTVFs не могут выполняться в чередующемся режиме, если они не используют константы времени выполнения.

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

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

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

  • Существует большое отклонение между предполагаемым и фактическим числом строк промежуточного результирующего набора (в данном случае 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],
       [fol].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
     INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession', '1-01-2013', '10-15-2014') AS [fol]
         ON [fo].[Order Key] = [fol].[Order Key]
        AND [fo].[City Key] = [fol].[City Key]
        AND [fo].[Customer Key] = [fol].[Customer Key]
        AND [fo].[Stock Item Key] = [fol].[Stock Item Key]
        AND [fo].[Order Date Key] = [fol].[Order Date Key]
        AND [fo].[Picked Date Key] = [fol].[Picked Date Key]
        AND [fo].[Salesperson Key] = [fol].[Salesperson Key]
        AND [fo].[Picker Key] = [fol].[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) и более поздних версий База данных Azure SQLУправляемый экземпляр Azure SQL

Оптимизация планов с учетом параметров (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.

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

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

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

Дополнительную информацию см. в APPROX_PERCENTILE_DISC и APPROX_PERCENTILE_CONT

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

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

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

Note

В документации термин 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 повышают затраты на выполнение инструкций DELETE и UPDATE.

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

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

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

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

Note

Использование пакетного режима для данных 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'));

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

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

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

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

  • Last updated on