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

Применимо к: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 2025
• Новые возможности SQL Server 2022
• Новые возможности SQL Server 2019
• Новые возможности SQL Server 2017

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

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

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

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

Чередующееся выполнение для MSTVFs

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

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

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

Для MSTVF используется фиксированная оценка кардинальности, равная 100, начиная с SQL Server 2014 (12.x), а для более ранних версий SQL Server — 1.

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

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

Вы можете увидеть фактический поток строк в сравнении с оценочным количеством строк. Есть три заслуживающие внимания области плана (направление — справа налево):

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

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

• Теперь сканирование таблицы MSTVF отражает точную оценку кардинальности. Кроме того, обратите внимание на изменение порядка выполнения этого сканирования таблицы и других операций.
• Что касается алгоритмов соединения, мы перешли с операции Nested Loops на операцию Hash Match, поскольку она более эффективна при большом количестве обрабатываемых строк.
• Также обратите внимание, что предупреждения о сбросе данных на диск больше не возникают, так как мы выделяем больший объём памяти на основе фактического количества строк, поступающего при сканировании таблицы MSTVF.

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

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

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

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

Как правило, чередующееся выполнение полезно для запросов в следующих случаях:

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

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

  Базовый SELECT * из MSTVF не выигрывает от перемежающегося выполнения.

Накладные расходы при чередовании выполнения

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

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

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

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

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

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

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

Кэширование чередующегося выполнения

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

Подстановка скалярных UDF

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

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

• Дополнительные сведения об оптимизации 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

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

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

• Хеш-соединения между большими таблицами построчного хранения
• Запросы с GROUP BY по множеству различных значений
• Агрегатные функции, такие как SUM, COUNT, MINMAXAVG
• Запросы с оконными функциями OVER, PARTITION BY и ORDER BY, включая агрегатные функции, ROW_NUMBER и RANK

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

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

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

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

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

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

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

Однако важно понимать, что две функции являются независимыми:

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

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

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

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

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

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

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

Что меняется при пакетном режиме в хранилище строк?

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

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

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

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

Remarks

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

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

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

В настоящее время для нового пакетного режима при сканировании rowstore существуют следующие ограничения:

• Это не применяется к таблицам OLTP в памяти и ни к каким индексам, кроме дисковых куч и B-деревьев.
• Оно также не срабатывает, если извлекается или фильтруется столбец типа large object (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)
• Режимы выполнения
• Руководство по архитектуре обработки запросов
• Справочник по операторам логического и физического плана выполнения
• ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
• Новые возможности SQL Server 2017
• Новые возможности SQL Server 2019
• Новые возможности SQL Server 2022
• Демонстрация интеллектуальной обработки запросов
• Свертывание констант и вычисление выражений
• Интеллектуальные демонстрации обработки запросов на GitHub
• Центр производительности для базы данных SQL Azure и ядра СУБД SQL Server
• Мониторинг производительности с использованием хранилища запросов
• Рекомендации по мониторингу рабочих нагрузок с помощью Хранилища запросов