Интеллектуальная обработка запросов в базах данных SQLIntelligent query processing in SQL databases

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server даБаза данных SQL Azure нетAzure Synapse Analytics (хранилище данных SQL) нетParallel Data WarehouseAPPLIES TO: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

Семейство функций интеллектуальной обработки запросов включает средства, которые значительно повышают производительность существующих рабочих нагрузок и требуют минимальных усилий при реализации для внедрения.The intelligent query processing (IQP) feature family includes features with broad impact that improve the performance of existing workloads with minimal implementation effort to adopt.

Интеллектуальная обработка запросов

Просмотрите это 6-минутное видео, чтобы получить общие сведения об интеллектуальной обработке запросов:Watch this 6-minute video for an overview of intelligent query processing:

Рабочие нагрузки можно автоматически сделать подходящими для интеллектуальной обработки запросов, включив для базы данных соответствующий уровень совместимости.You can make workloads automatically eligible for intelligent query processing by enabling the applicable database compatibility level for the database. Для этого можно использовать Transact-SQLTransact-SQL.You can set this using Transact-SQLTransact-SQL. Пример:For example:

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 150;

В приведенной ниже таблице представлены все функции интеллектуальной обработки запросов и предъявляемые ими требования к уровню совместимости базы данных.The following table details all intelligent query processing features, along with any requirement they have for database compatibility level.

| Функция интеллектуальной обработки запросовIQP Feature | Поддержка в Базе данных SQL Azure Supported in Azure SQL Database | Поддерживается в SQL ServerSupported in SQL Server |ОписаниеDescription | | --- | --- | --- |--- | | Адаптивные соединения в пакетном режимеAdaptive Joins (Batch Mode) | Да, при уровне совместимости 140Yes, under compatibility level 140| Да, начиная с SQL Server 2017 (14.x);SQL Server 2017 (14.x) при уровне совместимости 140Yes, starting in SQL Server 2017 (14.x);SQL Server 2017 (14.x) under compatibility level 140|При использовании адаптивных соединений тип соединения выбирается динамически во время выполнения в зависимости от фактических входных строк.Adaptive joins dynamically select a join type during runtime based on actual input rows.| | Приблизительный подсчет различных объектовApproximate Count Distinct | ДаYes| Да, начиная с SQL Server 2019 (15.x)SQL Server 2019 (15.x)Yes, starting in SQL Server 2019 (15.x)SQL Server 2019 (15.x)|Предоставление приблизительного значения COUNT DISTINCT в сценариях обработки больших данных с сохранением производительности и низким потреблением памяти.Provide approximate COUNT DISTINCT for big data scenarios with the benefit of high performance and a low memory footprint. | | Пакетный режим для данных rowstoreBatch mode on rowstore. | Да, при уровне совместимости 150Yes, under compatibility level 150| Да, начиная с SQL Server 2019 (15.x)SQL Server 2019 (15.x), при уровне совместимости 150Yes, starting in SQL Server 2019 (15.x)SQL Server 2019 (15.x) under compatibility level 150|Пакетный режим для рабочих нагрузок реляционного хранилища данных, ограниченных производительностью ЦП, без необходимости использовать индексы columnstore.Provide batch mode for CPU-bound relational DW workloads without requiring columnstore indexes. | | Выполнение с чередованиемInterleaved Execution | Да, при уровне совместимости 140Yes, under compatibility level 140| Да, начиная с SQL Server 2017 (14.x);SQL Server 2017 (14.x) при уровне совместимости 140Yes, starting in SQL Server 2017 (14.x);SQL Server 2017 (14.x) under compatibility level 140|Использование фактической кратности из выходных данных функции с табличным значением с несколькими инструкциями, обнаруженной при первой компиляции, вместо фиксированной оценки.Use the actual cardinality of the multi-statement table valued function encountered on first compilation instead of a fixed guess.| | Обратная связь по временно предоставляемому буферу памяти в пакетном режимеMemory Grant Feedback (Batch Mode) | Да, при уровне совместимости 140Yes, under compatibility level 140| Да, начиная с SQL Server 2017 (14.x);SQL Server 2017 (14.x) при уровне совместимости 140Yes, starting in SQL Server 2017 (14.x);SQL Server 2017 (14.x) under compatibility level 140|Если при выполнении запроса в пакетном режиме некоторые операции переносятся на диск, объем памяти для последующих выполнений увеличивается.If a batch mode query has operations that spill to disk, add more memory for consecutive executions. Если запрос потребляет более 50 % выделенной ему памяти, размер временно предоставляемого буфера памяти для последующих выполнений уменьшается.If a query wastes > 50% of the memory allocated to it, reduce the memory grant side for consecutive executions.| | Обратная связь по временно предоставляемому буферу памяти в строковом режимеMemory Grant Feedback (Row Mode) | Да, при уровне совместимости 150Yes, under compatibility level 150| Да, начиная с SQL Server 2019 (15.x)SQL Server 2019 (15.x), при уровне совместимости 150Yes, starting in SQL Server 2019 (15.x)SQL Server 2019 (15.x) under compatibility level 150|Если при выполнении запроса в построчном режиме некоторые операции переносятся на диск, объем памяти для последующих выполнений увеличивается.If a row mode query has operations that spill to disk, add more memory for consecutive executions. Если запрос потребляет более 50 % выделенной ему памяти, размер временно предоставляемого буфера памяти для последующих выполнений уменьшается.If a query wastes > 50% of the memory allocated to it, reduce the memory grant side for consecutive executions.| | Встраивание скалярных определяемых пользователем функций Scalar UDF Inlining. | нетNo | Да, начиная с SQL Server 2019 (15.x)SQL Server 2019 (15.x), при уровне совместимости 150Yes, starting in SQL Server 2019 (15.x)SQL Server 2019 (15.x) under compatibility level 150|Скалярные пользовательские функции преобразуются в эквивалентные реляционные выражения, которые "встраиваются" в вызывающий запрос, что часто приводит к существенному повышению производительности.Scalar UDFs are transformed into equivalent relational expressions that are "inlined" into the calling query, often resulting in significant performance gains.| | Отложенная компиляция табличных переменныхTable Variable Deferred Compilation | Да, при уровне совместимости 150Yes, under compatibility level 150| Да, начиная с SQL Server 2019 (15.x)SQL Server 2019 (15.x), при уровне совместимости 150Yes, starting in SQL Server 2019 (15.x)SQL Server 2019 (15.x) under compatibility level 150|Использование фактической кратности табличной переменной, обнаруженной при первой компиляции, вместо фиксированной оценки.Use the actual cardinality of the table variable encountered on first compilation instead of a fixed guess.|

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

Функция адаптивных соединений в пакетном режиме позволяет отложить выбор метода хэш-соединения или соединения вложенными цикламидо завершения сканирования первых входных данных с помощью одного кэшированного плана.The batch mode Adaptive Joins feature enables the choice of a Hash Join or Nested Loops Join method to be deferred until after the first input has been scanned, by using a single cached plan. Оператор адаптивного соединения определяет пороговое значение, по которому принимается решение о переключении на план вложенного цикла.The Adaptive Join operator defines a threshold that is used to decide when to switch to a Nested Loops plan. Таким образом, во время выполнения план может динамически переключаться на более эффективную стратегию соединения.Your plan can therefore dynamically switch to a better join strategy during execution.

Дополнительные сведения, в том числе об отключении адаптивных соединений без изменения уровня совместимости, см. в разделе Общие сведения об адаптивных соединениях.For more information, including how to disable Adaptive joins without changing the compatibility level, see Understanding Adaptive joins.

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

План после выполнения запроса в SQL ServerSQL Server включает минимальный объем памяти, необходимый для выполнения, а также оптимальный временно предоставляемый буфер памяти, позволяющий уместить в памяти все строки.A query's post-execution plan in SQL ServerSQL Server includes the minimum required memory needed for execution and the ideal memory grant size to have all rows fit in memory. Если размер временно предоставляемого буфера памяти выбран неправильно, производительность снижается.Performance suffers when memory grant sizes are incorrectly sized. Избыточные буферы ведут к потере памяти и снижению параллелизма.Excessive grants result in wasted memory and reduced concurrency. Недостаточные буферы ведут к затратной временной записи на диск.Insufficient memory grants cause expensive spills to disk. Обратная связь по временно предоставляемому буферу памяти в пакетном режиме, ориентированная на повторяющиеся рабочие процессы, пересчитывает фактическую требуемую память для запроса и затем обновляет значение временного буфера для кэшированного плана.By addressing repeating workloads, batch mode memory grant feedback recalculates the actual memory required for a query and then updates the grant value for the cached plan. При выполнении идентичной инструкции запроса используется пересмотренный размер временно предоставляемого буфера памяти, который уменьшает чрезмерные буферы, снижающие параллелизм, исправляет недостаточные буферы, вызывающие затратную временную запись на диск.When an identical query statement is executed, the query uses the revised memory grant size, reducing excessive memory grants that impact concurrency and fixing underestimated memory grants that cause expensive spills to disk. На следующем графе показан пример использования обратной связи по временно предоставляемому буферу памяти в пакетном режиме.The following graph shows one example of using batch mode adaptive memory grant feedback. Длительность первого выполнения запроса составила 88 секунд из-за высокого уровня временной записи на диск.For the first execution of the query, duration was 88 seconds due to high spills:

DECLARE @EndTime datetime = '2016-09-22 00:00:00.000';
DECLARE @StartTime datetime = '2016-09-15 00:00:00.000';
SELECT TOP 10 hash_unique_bigint_id
FROM dbo.TelemetryDS
WHERE Timestamp BETWEEN @StartTime and @EndTime
GROUP BY hash_unique_bigint_id
ORDER BY MAX(max_elapsed_time_microsec) DESC;

Высокий уровень временной записи на диск

С включенной обратной связью по временно предоставляемому буферу памяти длительность второго выполнения составила 1 секунду (ранее 88 секунд), при этом временная запись на диск полностью устранена, а временный буфер увеличен.With memory grant feedback enabled, for the second execution, duration is 1 second (down from 88 seconds), spills are removed entirely, and the grant is higher:

Временная запись на диск отсутствует.

Определение размера с помощью обратной связи по временно предоставляемому буферу памятиMemory grant feedback sizing

Для чрезмерных временно предоставляемых буферов памяти, когда предоставленный объем памяти больше чем в два раза превышает объем фактической используемой памяти, функция обратной связи пересчитывает временно предоставляемый буфер памяти и обновляет кэшированный план.For an excessive memory grant condition, if the granted memory is more than two times the size of the actual used memory, memory grant feedback will recalculate the memory grant and update the cached plan. Для планов, у которых размер временно предоставляемого буфера памяти меньше 1 МБ, пересчет по превышению не выполняется.Plans with memory grants under 1 MB will not be recalculated for overages. Для недостаточных временно предоставляемых буферов памяти, которые приводят к временной записи на диск для операторов пакетного режима, обратная связь по временно предоставляемому буферу памяти активирует пересчет буфера.For an insufficiently sized memory grant condition, that result in a spill to disk for batch mode operators, memory grant feedback will trigger a recalculation of the memory grant. События временной записи передаются в функцию обратной связи и могут быть предоставлены с помощью события XEvent spilling_report_to_memory_grant_feedback.Spill events are reported to memory grant feedback and can be surfaced via the spilling_report_to_memory_grant_feedback xEvent. Оно возвращает идентификатор узла из плана, а также объем временно записанных данных для этого узла.This event returns the node ID from the plan and spilled data size of that node.

Обратная связь по временно предоставляемому буферу памяти и сценарии, зависящие от параметровMemory grant feedback and parameter sensitive scenarios

Для сохранения оптимальности различным значениям параметров могут также потребоваться разные планы запроса.Different parameter values may also require different query plans in order to remain optimal. Такой тип запроса называется "зависящим от параметров".This type of query is defined as "parameter-sensitive." Для планов, зависящих от параметров, функция обратной связи по временно предоставляемому буферу памяти отключается для запроса, имеющего нестабильные требования к памяти.For parameter-sensitive plans, memory grant feedback will disable itself on a query if it has unstable memory requirements. После нескольких повторных выполнений запроса план отключается, что можно наблюдать, отслеживая событие XEvent memory_grant_feedback_loop_disabled.The plan is disabled after several repeated runs of the query and this can be observed by monitoring the memory_grant_feedback_loop_disabled xEvent. Дополнительные сведения о сканировании и чувствительности параметров см. в разделе Руководство по архитектуре обработки запросов.For more information about parameter sniffing and parameter sensitivity, refer to the Query Processing Architecture Guide.

Кэширование обратной связи по временно предоставляемому буферу памятиMemory grant feedback caching

Обратную связь можно хранить в кэшированном плане для однократного выполнения.Feedback can be stored in the cached plan for a single execution. Но именно последовательные выполнения этой инструкции позволяют использовать преимущества корректировки обратной связи по временно предоставляемому буферу памяти.It is the consecutive executions of that statement, however, that benefit from the memory grant feedback adjustments. Эта функция применяется к повторному выполнению инструкций.This feature applies to repeated execution of statements. Обратная связь по временно предоставляемому буферу памяти изменяет только кэшированный план.Memory grant feedback will change only the cached plan. Изменения сейчас не сохраняются в хранилище запросов.Changes are currently not captured in the Query Store. Обратная связь не сохраняется, если план исключается из кэша.Feedback is not persisted if the plan is evicted from cache. Кроме того, в случае перехода на другой ресурс обратная связь будет утеряна.Feedback will also be lost if there is a failover. Инструкция, использующая OPTION (RECOMPILE), создает план и не кэширует его.A statement using OPTION (RECOMPILE) creates a new plan and does not cache it. Из-за отсутствия кэширования обратная связь по временно предоставляемому буферу памяти не создается, а план не сохраняется для компиляции и выполнения.Since it is not cached, no memory grant feedback is produced and it is not stored for that compilation and execution. Но если эквивалентная инструкция (т. е. с тем же хэшем запроса), не использовавшая OPTION (RECOMPILE), была кэширована и затем повторно выполнена, последующая инструкция может использовать преимущества обратной связи по временно предоставляемому буферу памяти.However, if an equivalent statement (that is, with the same query hash) that did not use OPTION (RECOMPILE) was cached and then re-executed, the consecutive statement can benefit from memory grant feedback.

Отслеживание операций обратной связи по временно предоставляемому буферу памятиTracking memory grant feedback activity

Вы можете отслеживать события обратной связи по временно предоставляемому буферу памяти с помощью события xEvent memory_grant_updated_by_feedback.You can track memory grant feedback events using the memory_grant_updated_by_feedback xEvent. Оно отслеживает текущий журнал подсчета выполнений, количество изменений плана функцией обратной связи, оптимальный дополнительный временно предоставляемый буфер памяти перед изменением и оптимальный буфер после изменения кэшированного плана функцией обратной связи.This event tracks the current execution count history, the number of times the plan has been updated by memory grant feedback, the ideal additional memory grant before modification and the ideal additional memory grant after memory grant feedback has modified the cached plan.

Обратная связь по временно предоставляемому буферу памяти, регулятор ресурсов и указания запросаMemory grant feedback, resource governor and query hints

Фактический объем предоставляемой памяти учитывает лимит памяти запросов, определяемый регулятором ресурсов или указанием запроса.The actual memory granted honors the query memory limit determined by the resource governor or query hint.

Отключение сброса данных во временно предоставляемый буфер памяти в пакетном режиме без изменения уровня совместимостиDisabling batch mode memory grant feedback without changing the compatibility level

Сброс данных во временно предоставляемый буфер памяти можно отключить в области базы данных или инструкции, сохранив уровень совместимости базы данных 140 или более высокий.Memory grant feedback can be disabled at the database or statement scope while still maintaining database compatibility level 140 and higher. Чтобы отключить сброс данных во временно предоставляемый буфер памяти в пакетном режиме для всех запросов, выполняемых из базы данных, выполните следующую команду в контексте соответствующей базы данных:To disable batch mode memory grant feedback for all query executions originating from the database, execute the following within the context of the applicable database:

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

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

Когда этот параметр включен, он будет иметь соответствующее состояние в представлении sys.database_scoped_configurations.When enabled, this setting will appear as enabled in sys.database_scoped_configurations.

Чтобы снова включить сброс данных во временно предоставляемый буфер памяти в пакетном режиме для всех запросов, выполняемых из базы данных, выполните следующую команду в контексте соответствующей базы данных:To re-enable batch mode memory grant feedback for all query executions originating from the database, execute the following within the context of the applicable database:

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

-- Azure SQL Database, SQL Server 2019 and higher
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_MEMORY_GRANT_FEEDBACK = ON;

Вы также можете отключить сброс данных во временно предоставляемый буфер памяти в пакетном режиме для определенного запроса, назначив DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK в качестве указания запроса USE HINT.You can also disable batch mode memory grant feedback for a specific query by designating DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK as a USE HINT query hint. Пример:For example:

SELECT * FROM Person.Address  
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (USE HINT ('DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK')); 

Указание запроса USE HINT имеет приоритет над конфигурацией, областью действия которой является база данных, или флагом трассировки.A USE HINT query hint takes precedence over a database scoped configuration or trace flag setting.

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

Применимо к: SQL ServerSQL Server (начиная сSQL Server 2019 (15.x)SQL Server 2019 (15.x)), База данных SQL AzureAzure SQL Database **** Applies toSQL ServerSQL Server: SQL Server 2019 (15.x)SQL Server 2019 (15.x) (starting with База данных SQL AzureAzure SQL Database)

Обратная связь с временно предоставляемым буфером памяти в строковом режиме — это расширение функции обратной связи с временно предоставляемым буфером памяти в пакетном режиме путем настройки размеров временно предоставляемого буфера памяти для операторов пакетного и строкового режимов.Row mode memory grant feedback expands on the batch mode memory grant feedback feature by adjusting memory grant sizes for both batch and row mode operators.

Чтобы включить обратную связь с временно предоставляемым буфером памяти в строковом режиме в База данных SQL AzureAzure SQL Database, активируйте режим совместимости базы данных 150 для базы данных, к которой вы подключаетесь при выполнении запроса.To enable row mode memory grant feedback in База данных SQL AzureAzure SQL Database, enable database compatibility level 150 for the database you are connected to when executing the query.

Действие обратной связи с временно предоставляемым буфером памяти в строковом режиме можно просмотреть с помощью события XEvent memory_grant_updated_by_feedback.Row mode memory grant feedback activity will be visible via the memory_grant_updated_by_feedback XEvent.

С момента выпуска функции обратной связи с временно предоставляемым буфером памяти в строковом режиме для фактических планов после выполнения будут отображаться два новых атрибута плана запроса: IsMemoryGrantFeedbackAdjusted и LastRequestedMemory. Они добавляются в XML-элемент плана запроса MemoryGrantInfo.Starting with row mode memory grant feedback, two new query plan attributes will be shown for actual post-execution plans: IsMemoryGrantFeedbackAdjusted and LastRequestedMemory, which are added to the MemoryGrantInfo query plan XML element.

LastRequestedMemory позволяет просмотреть предоставленный в результате выполнения предыдущего запроса объем памяти в килобайтах (КБ). LastRequestedMemory shows the granted memory in Kilobytes (KB) from the prior query execution. Атрибут IsMemoryGrantFeedbackAdjusted позволяет проверить состояние обратной связи с временно предоставляемым буфером памяти для инструкции в рамках фактического плана выполнения запроса. IsMemoryGrantFeedbackAdjusted attribute allows you to check the state of memory grant feedback for the statement within an actual query execution plan. Ниже приведены значения, отображаемые в этом атрибуте:Values surfaced in this attribute are as follows:

Значение IsMemoryGrantFeedbackAdjustedIsMemoryGrantFeedbackAdjusted Value DescriptionDescription
Нет: первое выполнениеNo: First Execution Обратная связь с временно предоставляемым буфером памяти не настраивает память для первой компиляции и связанной с ней операции выполнения.Memory grant feedback does not adjust memory for the first compile and associated execution.
Нет: точное предоставлениеNo: Accurate Grant Если не выполняется временная запись на диск и в инструкции используется не менее 50 % объема предоставленной памяти, обратная связь с временно предоставляемым буфером памяти не активируется.If there is no spill to disk and the statement uses at least 50% of the granted memory, then memory grant feedback is not triggered.
Нет: обратная связь отключенаNo: Feedback disabled Если обратная связь с временно предоставляемым буфером памяти непрерывно активируется и сопровождается постоянным увеличением и уменьшением объема памяти, мы отключим обратную связь с временно предоставляемым буфером памяти для этой инструкции.If memory grant feedback is continually triggered and fluctuates between memory-increase and memory-decrease operations, we will disable memory grant feedback for the statement.
Да: настройкаYes: Adjusting Обратная связь с временно предоставляемым буфером памяти применена, и ее можно дополнительно настроить для следующего выполнения.Memory grant feedback has been applied and may be further adjusted for the next execution.
Да: объем стабиленYes: Stable Обратная связь с временно предоставляемым буфером памяти применена, и объем памяти теперь стабилен. Это означает, что предоставленный для предыдущего выполнения объем эквивалентен предоставленному для текущего выполнения.Memory grant feedback has been applied and granted memory is now stable, meaning that what was last granted for the previous execution is what was granted for the current execution.

Отключение сброса данных во временно предоставляемый буфер памяти в строчном режиме без изменения уровня совместимостиDisabling row mode memory grant feedback without changing the compatibility level

Сброс данных во временно предоставляемый буфер памяти в строчном режиме можно отключить в области базы данных или инструкции, сохранив уровень совместимости базы данных 150 и выше.Row mode memory grant feedback can be disabled at the database or statement scope while still maintaining database compatibility level 150 and higher. Чтобы отключить сброс данных во временно предоставляемый буфер памяти в строчном режиме для всех запросов, выполняемых из базы данных, выполните следующую команду в контексте соответствующей базы данных:To disable row mode memory grant feedback for all query executions originating from the database, execute the following within the context of the applicable database:

ALTER DATABASE SCOPED CONFIGURATION SET ROW_MODE_MEMORY_GRANT_FEEDBACK = OFF;

Чтобы повторно включить сброс данных во временно предоставляемый буфер памяти в строчном режиме для всех запросов, выполняемых из базы данных, выполните следующую команду в контексте соответствующей базы данных:To re-enable row mode memory grant feedback for all query executions originating from the database, execute the following within the context of the applicable database:

ALTER DATABASE SCOPED CONFIGURATION SET ROW_MODE_MEMORY_GRANT_FEEDBACK = ON;

Вы также можете отключить сброс данных во временно предоставляемый буфер памяти в строковом режиме для определенного запроса, назначив DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK в качестве указания запроса USE HINT.You can also disable row mode memory grant feedback for a specific query by designating DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK as a USE HINT query hint. Пример:For example:

SELECT * FROM Person.Address  
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (USE HINT ('DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK')); 

Указание запроса USE HINT имеет приоритет над конфигурацией, областью действия которой является база данных, или флагом трассировки.A USE HINT query hint takes precedence over a database scoped configuration or trace flag setting.

Выполнение с чередованием для MSTVFInterleaved execution for MSTVFs

При выполнении с чередованием используется фактическое количество строк из функции для принятия обоснованного решения о плане запроса.With interleaved execution, the actual row counts from the function are used to make better-informed downstream query plan decisions. См. дополнительные сведения о функциях с табличным значением с несколькими инструкциями (MSTVF).For more information on multi-statement table-valued functions (MSTVFs), see Table-Valued Functions.

Выполнение с чередованием изменяет однонаправленную границу между этапами оптимизации и выполнения для выполнения с одним запросом и позволяет планам адаптироваться с учетом пересмотренных оценок кратности.Interleaved execution changes the unidirectional boundary between the optimization and execution phases for a single-query execution and enables plans to adapt based on the revised cardinality estimates. Если во время оптимизации нам встречается кандидат на выполнение с чередованием, который сейчас является функциями с табличным значением с несколькими инструкциями (MSTVF) , мы приостановим оптимизацию, выполним соответствующее поддерево, запишем точные оценки кратности и возобновим оптимизацию для нисходящих операций.During optimization if we encounter a candidate for interleaved execution, which is currently multi-statement table-valued functions (MSTVFs), we will pause optimization, execute the applicable subtree, capture accurate cardinality estimates, and then resume optimization for downstream operations.

Функции MSTVF имеют фиксированное предполагаемое значение кратности 100 начиная с SQL Server 2014 (12.x)SQL Server 2014 (12.x) и 1 в более ранних версиях SQL ServerSQL Server.MSTVFs have a fixed cardinality guess of 100 starting with SQL Server 2014 (12.x)SQL Server 2014 (12.x), and 1 for earlier SQL ServerSQL Server versions. Выполнение с чередованием помогает устранить проблемы с производительностью рабочих нагрузок, вызванные фиксированными оценками кратности, которые связаны с функциями MSTVF.Interleaved execution helps workload performance issues that are due to these fixed cardinality estimates associated with MSTVFs. Дополнительные сведения о функциях MSTVF см. в разделе Создание определяемых пользователем функций (ядро СУБД).For more information on MSTVFs, see Create User-defined Functions (Database Engine).

На приведенном ниже рисунке изображены выходные данные статистики активных запросов — подмножество общего плана выполнения, показывающее влияние фиксированных оценок кратности из функций MSTVF.The following image depicts a Live Query Statistics output, a subset of an overall execution plan that shows the impact of fixed cardinality estimates from MSTVFs. Вы можете сравнить фактическую передачу строк с предполагаемым значением.You can see the actual row flow vs. estimated rows. Следует отметить три области плана (переход справа налево):There are three noteworthy areas of the plan (flow is from right to left):

  1. Сканирование таблицы MSTVF имеет фиксированную оценку в 100 строк.The MSTVF Table Scan has a fixed estimate of 100 rows. Однако в данном примере через это сканирование таблицы MSTVF передается 527 597 строк, как видно в статистике активных запросов — 527597 из 100, то есть фиксированная оценка имеет значительное отклонение.For this example, however, there are 527,597 rows flowing through this MSTVF Table Scan, as seen in Live Query Statistics via the 527597 of 100 actual of estimated - so the fixed estimate is significantly skewed.
  2. Для операции вложенных циклов предполагается, что наружная часть соединения возвращает всего 100 строк.For the Nested Loops operation, only 100 rows are assumed to be returned by the outer side of the join. Учитывая, как много строк функция MSTVF возвращает на самом деле, лучше всего перейти на другой алгоритм соединения.Given the high number of rows actually being returned by the MSTVF, you are likely better off with a different join algorithm altogether.
  3. Для операции хэш-совпадений обратите внимание на небольшой предупреждающий символ, который в данном случае указывает на временную запись на диск.For the Hash Match operation, notice the small warning symbol, which in this case is indicating a spill to disk.

Поток строк и предполагаемые строки

Сравним предыдущий план с фактическим планом, созданным при включенном выполнении с чередованием:Contrast the prior plan with the actual plan generated with interleaved execution enabled:

План с чередованием

  1. Обратите внимание, что сканирование таблицы MSTVF отражает точную оценку кратности.Notice that the MSTVF table scan now reflects an accurate cardinality estimate. Также обратите внимание на переупорядочение этого сканирования таблицы и других операций.Also notice the re-ordering of this table scan and the other operations.
  2. Что касается алгоритмов соединения, мы перешли от операции вложенных циклов Loop к операции хэш-совпадений, которая лучше подходит для такого большого числа строк.And regarding join algorithms, we have switched from a Nested Loop operation to a Hash Match operation instead, which is more optimal given the large number of rows involved.
  3. Также обратите внимание, что прекратились предупреждения о временной записи, так как мы выделяем больше памяти на основе истинного количества строк, поступающих из сканирования таблицы MSTVF.Also notice that we no longer have spill-warnings, as we're granting more memory based on the true row count flowing from the MSTVF table scan.

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

Инструкции ссылок MSTVF в выполнении с чередованием сейчас должны быть доступны только для чтения и не входить в состав операции изменения данных.MSTVF referencing statements in interleaved execution must currently be read-only and not part of a data modification operation. Кроме того, функции MSTVF нельзя выполнять с чередованием, если в них не используются константы времени выполнения.Also, MSTVFs are not eligible for interleaved execution if they do not use runtime constants.

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

Обычно чем выше отклонение между предполагаемым и фактическим числом строк в сочетании с числом нисходящих операций плана, тем больше негативное влияние на производительность.In general, the higher the skew between the estimated vs. actual number of rows, coupled with the number of downstream plan operations, the greater the performance impact. В общем случае выполнение с чередованием оказывается полезным для запросов, где выполняются следующие условия:In general, interleaved execution benefits queries where:

  1. Имеется большое отклонение между предполагаемым и фактическим числом строк для промежуточного результирующего набора (в данном случае — MSTVF).There is a large skew between the estimated vs. actual number of rows for the intermediate result set (in this case, the MSTVF).
  2. Весь запрос чувствителен к изменению размера промежуточного результата.And the overall query is sensitive to a change in the size of the intermediate result. Обычно это происходит, когда над поддеревом в плане запроса имеется сложное дерево.This typically happens when there is a complex tree above that subtree in the query plan. Выполнение с чередованием не принесет никакой выгоды для простой инструкции SELECT * из MSTVF.A simple SELECT * from an MSTVF will not benefit from interleaved execution.

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

Издержки должны быть минимальными либо отсутствовать.The overhead should be minimal-to-none. Функции MSTVF уже были материализованы перед появлением выполнения с чередованием, но различие состоит в том, что теперь мы разрешаем отложенную оптимизацию и используем оценку кратности для набора материализованных строк.MSTVFs were already being materialized prior to the introduction of interleaved execution, however the difference is that now we're now allowing deferred optimization and are then leveraging the cardinality estimate of the materialized row set. Как и в случае с любым планом, влияющим на изменения, некоторые планы могут изменяться таким образом, что при улучшенной кратности для поддерева мы получаем ухудшенный план для всего запроса в целом.As with any plan affecting changes, some plans could change such that with better cardinality for the subtree we get a worse plan for the query overall. В качестве устранения этой проблемы можно отменить изменения уровня совместимости или использовать хранилище запросов для принудительного применения нерегрессированной версии плана.Mitigation can include reverting the compatibility level or using Query Store to force the non-regressed version of the plan.

Выполнение с чередованием и последовательные выполненияInterleaved execution and consecutive executions

После кэширования плана выполнения с чередованием этот план с оценками, пересмотренными при первом выполнении, используется для последующих выполнений без повторного создания экземпляра выполнения с чередованием.Once an interleaved execution plan is cached, the plan with the revised estimates on the first execution is used for consecutive executions without re-instantiating interleaved execution.

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

Вы можете просмотреть атрибуты использования в фактическом плане выполнения запроса:You can see usage attributes in the actual query execution plan:

Атрибут плана выполненияExecution Plan attribute DescriptionDescription
ContainsInterleavedExecutionCandidatesContainsInterleavedExecutionCandidates Применяется к узлу QueryPlan.Applies to the QueryPlan node. Значение true означает, что план содержит кандидаты на выполнение с чередованием.When true, means the plan contains interleaved execution candidates.
IsInterleavedExecutedIsInterleavedExecuted Атрибут элемента RuntimeInformation под RelOp для узла TVF.Attribute of the RuntimeInformation element under the RelOp for the TVF node. Если значение равно true, значит, операция была материализована как часть операции выполнения с чередованием.When true, means the operation was materialized as part of an interleaved execution operation.

Вы также можете отслеживать случаи выполнения с чередованием с помощью следующих событий xEvents:You can also track interleaved execution occurrences via the following xEvents:

xEventxEvent DescriptionDescription
interleaved_exec_statusinterleaved_exec_status Это событие возникает, когда происходит выполнение с чередованием.This event fires when interleaved execution is occurring.
interleaved_exec_stats_updateinterleaved_exec_stats_update Это событие описывает оценки кратности, обновленные выполнением с чередованием.This event describes the cardinality estimates updated by interleaved execution.
Interleaved_exec_disabled_reasonInterleaved_exec_disabled_reason Это событие возникает, когда запрос с кандидатом на выполнение с чередованием не получает такое выполнение.This event fires when a query with a possible candidate for interleaved execution does not actually get interleaved execution.

Чтобы разрешить выполнению с чередованием пересматривать оценки кратности MSTVF, нужно выполнить запрос.A query must be executed in order to allow interleaved execution to revise MSTVF cardinality estimates. При этом предполагаемый план выполнения по-прежнему сообщает о наличии кандидатов на выполнение с чередованием с помощью атрибута showplan ContainsInterleavedExecutionCandidates.However, the estimated execution plan still shows when there are interleaved execution candidates via the ContainsInterleavedExecutionCandidates showplan attribute.

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

Если план удаляется или извлекается из кэша, при выполнении запроса появляется новая компиляция, в которой используется исполнение чередованием.If a plan is cleared or evicted from cache, upon query execution there is a fresh compilation that uses interleaved execution. Инструкция с использованием OPTION (RECOMPILE) создаст план с использованием выполнения с чередованием, но без кэширования.A statement using OPTION (RECOMPILE) will create a new plan using interleaved execution and not cache it.

Взаимодействие выполнения с чередованием и хранилища запросовInterleaved execution and query store interoperability

Планы с использованием выполнения с чередованием можно применять принудительно.Plans using interleaved execution can be forced. План представляет собой версию с оценками кратности, исправленными на основе начального выполнения.The plan is the version that has corrected cardinality estimates based on initial execution.

Отключение выполнения с чередованием без изменения уровня совместимостиDisabling interleaved execution without changing the compatibility level

Выполнение с чередованием можно отключить в области базы данных или инструкции, сохранив уровень совместимости базы данных 140 или более высокий.Interleaved execution can be disabled at the database or statement scope while still maintaining database compatibility level 140 and higher. Чтобы отключить выполнение с чередованием для всех запросов, выполняемых из базы данных, выполните следующую команду в контексте соответствующей базы данных:To disable interleaved execution for all query executions originating from the database, execute the following within the context of the applicable database:

-- 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.When enabled, this setting will appear as enabled in sys.database_scoped_configurations. Чтобы снова включить выполнение с чередованием для всех запросов, выполняемых из базы данных, выполните следующую команду в контексте соответствующей базы данных:To re-enable interleaved execution for all query executions originating from the database, execute the following within the context of the applicable database:

-- 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.You can also disable interleaved execution for a specific query by designating DISABLE_INTERLEAVED_EXECUTION_TVF as a USE HINT query hint. Пример:For example:

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 имеет приоритет над конфигурацией, областью действия которой является база данных, или флагом трассировки.A USE HINT query hint takes precedence over a database scoped configuration or trace flag setting.

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

Применимо к: SQL ServerSQL Server (начиная сSQL Server 2019 (15.x)SQL Server 2019 (15.x)), База данных SQL AzureAzure SQL Database **** Applies toSQL ServerSQL Server: SQL Server 2019 (15.x)SQL Server 2019 (15.x) (starting with База данных SQL AzureAzure SQL Database)

Отложенная компиляция табличных переменных позволяет оптимизировать план и повысить общую производительность для запросов, ссылающихся на табличные переменные.Table variable deferred compilation improves plan quality and overall performance for queries referencing table variables. Во время оптимизации и первичной компиляции плана эта функция будет распространять оценки кратности, основанные на фактическом числе строк табличных переменных.During optimization and initial plan compilation, this feature will propagate cardinality estimates that are based on actual table variable row counts. Эти точные сведения о числе строк затем будут использоваться для оптимизации последующих операций планирования.This exact row count information will then be used for optimizing downstream plan operations.

При отложенной компиляции табличных переменных компиляция инструкции со ссылкой на табличную переменную откладывается до момента первого фактического выполнения инструкции.With table variable deferred compilation, compilation of a statement that references a table variable is deferred until the first actual execution of the statement. Это поведение отложенной компиляции совпадает с поведением временных таблиц.This deferred compilation behavior is identical to the behavior of temporary tables. Такое изменение позволяет использовать реальную кратность вместо обычного предположения по одной строке.This change results in the use of actual cardinality instead of the original one-row guess.

Чтобы включить отложенную компиляцию табличных переменных, активируйте уровень совместимости 150 для базы данных, к которой вы подключаетесь при выполнении запроса.To enable the public preview of table variable deferred compilation, enable database compatibility level 150 for the database you're connected to when the query runs.

При отложенной компиляции табличных переменных другие характеристики табличных переменных не изменяются.Table variable deferred compilation doesn't change any other characteristics of table variables. Например, в табличные переменные не добавляется статистика по столбцам.For example, this feature doesn't add column statistics to table variables.

Также при использовании этой функции не повышается частота перекомпиляции.Table variable deferred compilation doesn't increase recompilation frequency. Эта функция эффективна при начальной компиляции.Rather, it shifts where the initial compilation occurs. Итоговый кэшированный план создается на основе числа строк табличных переменных начальной отложенной компиляции.The resulting cached plan generates based on the initial deferred compilation table variable row count. Кэшированный план повторно используется последующими запросамиThe cached plan is reused by consecutive queries. до тех пор, пока план не будет исключен или перекомпилирован.It's reused until the plan is evicted or recompiled.

Число строк табличных переменных, используемых для начальной компиляции плана, представляет стандартное значение, которое может отличаться от предположительного фиксированного числа строк.Table variable row count that is used for initial plan compilation represents a typical value might be different from a fixed row count guess. Если оно отличается, последующие операции будут более производительными.If it's different, downstream operations will benefit. Если число строк табличных переменных существенно меняется при каждом выполнении, эта функция не поможет повысить производительность.Performance may not be improved by this feature if the table variable row count varies significantly across executions.

Отключение отложенной компиляции табличной переменной без изменения уровня совместимостиDisabling table variable deferred compilation without changing the compatibility level

Отключите отложенную компиляцию табличной переменной в области базы данных или инструкции, сохранив уровень совместимости базы данных 150 и выше.Disable table variable deferred compilation at the database or statement scope while still maintaining database compatibility level 150 and higher. Чтобы отключить отложенную компиляцию табличной переменной для всех запросов, поступающих из базы данных, выполните следующий пример в контексте соответствующей базы данных:To disable table variable deferred compilation for all query executions originating from the database, execute the following example within the context of the applicable database:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Чтобы повторно включить отложенную компиляцию табличной переменной для всех запросов, поступающих из базы данных, выполните следующий пример в контексте соответствующей базы данных:To re-enable table variable deferred compilation for all query executions originating from the database, execute the following example within the context of the applicable database:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Вы также можете отключить отложенную компиляцию табличной переменной для определенного запроса, назначив DISABLE_DEFERRED_COMPILATION_TV в качестве указания запроса USE HINT.You can also disable table variable deferred compilation for a specific query by assigning DISABLE_DEFERRED_COMPILATION_TV as a USE HINT query hint. Пример:For example:

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'));

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

Применимо к: SQL ServerSQL Server (начиная с SQL Server 2019 (15.x)SQL Server 2019 (15.x)) Applies to: (starting with )

Функция встраивания скалярных определяемых пользователем функций позволяет автоматически преобразовать скалярные определяемые пользовательские функции в реляционные выражения.Scalar UDF inlining automatically transforms scalar UDFs into relational expressions. Затем они внедряются в вызывающий SQL-запрос.It embeds them in the calling SQL query. Такое преобразование повышает производительность рабочих нагрузок, которые используют скалярные определяемые пользователем функции.This transformation improves the performance of workloads that take advantage of scalar UDFs. Встраивание скалярных определяемых пользователем функций способствует оптимизации с учетом стоимости операций, выполняемых внутри определяемых пользователем функций.Scalar UDF inlining facilitates cost-based optimization of operations inside UDFs. Это обеспечивает эффективные планы выполнения с поддержкой наборов и параллелизма вместо неэффективных, итеративных и последовательных планов.The results are efficient, set-oriented, and parallel instead of inefficient, iterative, serial execution plans. Эта функция включена по умолчанию на уровне совместимости базы данных 150.This feature is enabled by default under database compatibility level 150.

Дополнительные сведения см. в разделе Встраивание скалярных функций, определяемых пользователем.For more information, see Scalar UDF Inlining.

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

Применимо к: SQL ServerSQL Server (начиная сSQL Server 2019 (15.x)SQL Server 2019 (15.x)), База данных SQL AzureAzure SQL Database **** Applies toSQL ServerSQL Server: SQL Server 2019 (15.x)SQL Server 2019 (15.x) (starting with База данных SQL AzureAzure SQL Database)

Приблизительная обработка запросов — это новое семейство функций.Approximate query processing is a new feature family. Оно позволяет агрегировать большие наборы данных, для которых скорость реагирования намного важнее абсолютной точности.It aggregates across large datasets where responsiveness is more critical than absolute precision. В качестве примера предположим, что нам нужно вычислить выражение COUNT(DISTINCT()) по 10 миллиардам строк, чтобы отобразить результат на панели мониторинга.An example is calculating a COUNT(DISTINCT()) across 10 billion rows, for display on a dashboard. Абсолютная точность здесь не требуется, но критически важна скорость реагирования.In this case, absolute precision isn't important, but responsiveness is critical. Новая агрегатная функция APPROX_COUNT_DISTINCT возвращает приблизительное количество содержащихся в группе уникальных значений, не равных NULL.The new APPROX_COUNT_DISTINCT aggregate function returns the approximate number of unique non-null values in a group.

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

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

Применимо к: SQL ServerSQL Server (начиная сSQL Server 2019 (15.x)SQL Server 2019 (15.x)), База данных SQL AzureAzure SQL Database **** Applies toSQL ServerSQL Server: SQL Server 2019 (15.x)SQL Server 2019 (15.x) (starting with База данных SQL AzureAzure SQL Database)

Пакетный режим для данных rowstore обеспечивает выполнение в пакетном режиме для аналитических рабочих нагрузок без необходимости использовать индексы columnstore.Batch mode on rowstore enables batch mode execution for analytic workloads without requiring columnstore indexes. Эта функция поддерживает выполнение в пакетном режиме и фильтры по битовым картам для кучи на диске и индексов сбалансированного дерева.This feature supports batch mode execution and bitmap filters for on-disk heaps and B-tree indexes. Пакетный режим rowstore обеспечивает поддержку для всех операторов, доступных в этом режиме.Batch mode on rowstore enables support for all existing batch mode-enabled operators.

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

В SQL Server 2012 (11.x)SQL Server 2012 (11.x) появилась новая функция для ускорения аналитических рабочих нагрузок — индексы columnstore.SQL Server 2012 (11.x)SQL Server 2012 (11.x)introduced a new feature to accelerate analytical workloads: columnstore indexes. С каждым последующим выпуском мы расширяли возможности использования индексов columnstore и улучшали их производительность.We expanded the use cases and improved the performance of columnstore indexes in each subsequent release. До этого момента мы представляли и документировали все эти возможности как одну функцию.Until now, we surfaced and documented all these capabilities as a single feature. Индексы columnstore создаются на уровне таблиц.You create columnstore indexes on your tables. Благодаря этому быстрее выполняются аналитические рабочие нагрузки.And your analytical workload goes faster. Но на самом деле здесь применяются два связанных, но различных набора технологий.However, there are two related but distinct sets of technologies:

  • Индексы columnstore позволяют аналитическим запросам получать доступ к данным только в требуемых столбцах.With columnstore indexes, analytical queries access only the data in the columns they need. Кроме того, сжатие в формате columnstore намного эффективнее, чем для традиционных индексов rowstore.Page compression in the columnstore format is also more effective than compression in traditional rowstore indexes.
  • При обработке в пакетном режиме операторы запросов выполняются более эффективно.With batch mode processing, query operators process data more efficiently. Они работают по пакету строк, а не по одной строке за раз.They work on a batch of rows instead of one row at a time. С обработкой в пакетном режиме также связан ряд других улучшений масштабируемости.A number of other scalability improvements are tied to batch mode processing. Дополнительные сведения о пакетном режиме см. в разделе Режимы выполнения.For more information on batch mode, see Execution Modes.

Эти два набора функций взаимодействуют, чтобы оптимизировать скорость выполнения операций ввода-вывода и использование ЦП.The two sets of features work together to improve input/output (I/O) and CPU use:

  • Благодаря индексам columnstore в памяти помещается больше данных.By using columnstore indexes, more of your data fits in memory. Это снижает нагрузку на подсистему ввода-вывода.That reduces the need for I/O.
  • При обработке в пакетном режиме ресурсы ЦП используются более эффективно.Batch mode processing uses CPU more efficiently.

Эти две технологии совместно используются везде, где это возможно, для получения дополнительных преимуществ.The two technologies take advantage of each other whenever possible. Например, статические выражения в пакетном режиме можно вычислить в рамках сканирования индекса columnstore.For example, batch mode aggregates can be evaluated as part of a columnstore index scan. Кроме того, с помощью соединений и статических вычислений пакетного режима гораздо более эффективно обрабатываются данные columnstore, которые сжаты с использованием кодирования по длине серий.Also columnstore data that's compressed is processed by using run-length encoding much more efficiently with batch mode joins and batch mode aggregates.

Однако важно понимать, что эти две функции не зависят друг от друга.It is importand to understand however, that the two features are independent:

  • Можно создать план со строковым режимом, который использует индексы columnstore.You get row mode plans that use columnstore indexes.
  • Можно создать план с пакетным режимом, который использует только индексы rowstore.You can get batch mode plans that use only rowstore indexes.

Но обычно совместное использование этих компонентов дает наилучший результат.You usually get the best results when you use the two features together. Поэтому до текущего момента оптимизатор запросов SQL Server применял пакетную обработку только для запросов, которые включают хотя бы одну таблицу с индексом columnstore.So until now, the SQL Server query optimizer considered batch mode processing only for queries that involve at least one table with a columnstore index.

Индексы columnstore могут не подходить для некоторых приложений.Columnstore indexes may not be appropriate for some applications. Приложение может использовать другие функции, которые не совместимы с индексами columnstore.An application might use some other feature that isn't supported with columnstore indexes. Например, изменения на месте не совместимы со сжатием columnstore.For example, in-place modifications are not compatible with columnstore compression. Поэтому таблицы с кластеризованными индексами columnstore не поддерживают триггеры.So triggers aren't supported on tables with clustered columnstore indexes. Что еще важнее, индексы columnstore повышают затраты на выполнение инструкций DELETE и UPDATE.More importantly, columnstore indexes add overhead for DELETE and UPDATE statements.

Для некоторых гибридных транзакционно-аналитических рабочих нагрузок издержки на транзакционную нагрузку перевешивают преимущества от использования индексов columnstore.For some hybrid transactional-analytical workloads, the overhead of a transactional workload outweighs the benefits gained from using columnstore indexes. В таких сценариях можно улучшить использование ЦП, применяя исключительно режим пакетной обработки.Such scenarios can benefit from improved CPU usage by employing batch mode processing alone. Поэтому функция "Пакетный режим для данных rowstore" позволяет применять пакетный режим для всех запросов независимо от типа используемых индексов.That is why the batch-mode-on-rowstore feature considers batch mode for all queries regardless of what type of indexes are involved.

Рабочие нагрузки, для которых целесообразно использовать пакетный режима для данных rowstoreWorkloads that might benefit from batch mode on rowstore

Пакетный режим для данных rowstore предоставляет преимущества для рабочих нагрузок со следующими характеристиками:The following workloads might benefit from batch mode on rowstore:

  • Если значительная часть рабочей нагрузки состоит из аналитических запросов.A significant part of the workload consists of analytical queries. Обычно такие запросы используют соединения или статистические выражения для обработки сотен тысяч строк или даже больше.Usually, these queries have operators like joins or aggregates that process hundreds of thousands of rows or more.
  • Если рабочая нагрузка сильно зависит от ЦП.The workload is CPU bound. Для всех случаев, когда узким местом остается скорость ввода и вывода, рекомендуется при любой возможности применять индекс columnstore.If the bottleneck is I/O, it is still recommended that you consider a columnstore index, where possible.
  • Если создание индекса columnstore сопряжено со слишком большими транзакционными расходами для рабочей нагрузки.Creating a columnstore index adds too much overhead to the transactional part of your workload. Возможно также, что индекс columnstore создать нельзя из-за зависимости приложения от функции, которая пока не поддерживает работу с индексами columnstore.Or, creating a columnstore index isn't feasible because your application depends on a feature that's not yet supported with columnstore indexes.

Примечание

Использование пакетного режима для данных rowstore помогает только сократить потребление ресурсов ЦП.Batch mode on rowstore helps only by reducing CPU consumption. Если же узким местом являются операции ввода-вывода и данные не кэшируются ("холодный" кэш), использование пакетного режима для rowstore не сократит время, затраченное на выполнение запроса.If your bottleneck is IO-related, and data is not already cached ("cold" cache), batch mode on rowstore will NOT improve elapsed time. Аналогичным образом, если на компьютере не хватает памяти для кэширования всех данных, повышение производительности маловероятно.Similarly, if there is not enough memory on the machine to cache all data, a performance improvement is unlikely.

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

Задайте для базы данных уровень совместимости 150.Set the database to to compatibility level 150. Другие изменения не требуются.No other code changes are required.

Даже если запрос не обращается к таблицам с индексами columnstore, обработчик запросов использует эвристику, чтобы решить, следует ли рассматривать пакетный режим.Even if a query does not involve any table with a columnstore index, the query processor now uses heuristics to decide whether to consider batch mode. Этот эвристический анализ включает следующее:The heuristics consist of these checks:

  1. Первоначальной проверки размеров таблиц, используемых операторов и предполагаемого количества элементов во входном запросе.An initial check of table sizes, operators used, and estimated cardinalities in the input query.
  2. Дополнительных проверок, так как оптимизатор обнаруживает новые, более дешевые планы для запроса.Additional checkpoints, as the optimizer discovers new, cheaper plans for the query. Если эти альтернативные планы используют пакетный режим незначительно, оптимизатор прекратит изучение альтернатив с пакетным режимом.If these alternative plans don't make significant use of batch mode, the optimizer stops exploring batch mode alternatives.

Если для данных rowstore используется пакетный режим, фактический режим выполнения будет обозначен как batch mode (пакетный режим) в плане запроса.If batch mode on rowstore is used, you see the actual run mode as batch mode in the query plan. Оператор сканирования использует пакетный режим для кучи на диске и индексов сбалансированного дерева.The scan operator uses batch mode for on-disk heaps and B-tree indexes. При этом сканировании пакетного режима можно оценить фильтры растрового изображения в пакетном режиме.This batch mode scan can evaluate batch mode bitmap filters. Вы можете заметить в плане и другие операторы пакетного режима.You might also see other batch mode operators in the plan. Например, хэш-соединения, статические операции на основе хэша, сортировки, статистические операции с окнами, фильтры, объединение и операторы вычисления скалярного значения.Examples are hash joins, hash-based aggregates, sorts, window aggregates, filters, concatenation, and compute scalar operators.

RemarksRemarks

Планы запросов не всегда используют пакетный режим.Query plans don't always use batch mode. Оптимизатор запросов может определить, что пакетный режим не улучшит обработку запроса.The Query Optimizer might decide that batch mode isn't beneficial for the query.

Пространство поиска оптимизатора запросов изменяется.The Query Optimizer's search space is changing. Например, план в строковом режиме может не совпадать с планом, который вы получите на более низком уровне совместимости.So if you get a row mode plan, it might not be the same as the plan you get in a lower compatibility level. А план в пакетном режиме может не совпадать с планом, который вы получите для индекса columnstore.And if you get a batch mode plan, it might not be the same as the plan you get with a columnstore index.

Новый режим сканирования пакетного режима для данных rowstore может изменять планы для запросов, в которых сочетаются индексы columnstore и rowstore.Plans might also change for queries that mix columnstore and rowstore indexes because of the new batch mode rowstore scan.

Для нового сканирования пакетного режима для данных rowstore действует ряд ограничений:There are current limitations for the new batch mode on rowstore scan:

  • Сканирование не будет использоваться для таблиц OLTP, выполняющейся в памяти, или для любых других индексов, отличных от индексов в виде куч на диске и сбалансированных деревьев.It won't kick in for in-memory OLTP tables or for any index other than on-disk heaps and B-trees.
  • Также оно не применяется, если LOB-столбец извлекается или фильтруется.It also won't kick in if a large object (LOB) column is fetched or filtered. Это ограничение относится и к наборам разреженных столбцов и XML-столбцам.This limitation includes sparse column sets and XML columns.

Есть запросы, для которых пакетный режим не применяется даже с индексами columnstore.There are queries that batch mode isn't used for even with columnstore indexes. В качестве примера можно назвать запросы с курсорами.Examples are queries that involve cursors. Эти исключения относятся и к пакетному режиму для индексов rowstore.These same exclusions also extend to batch mode on rowstore.

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

Параметр BATCH_MODE_ON_ROWSTORE в конфигурации уровня базы данных включен по умолчанию.The BATCH_MODE_ON_ROWSTORE database scoped configuration is on by default. Он позволяет отключить пакетный режим для индексов rowstore, не требуя изменять уровень совместимости базы данных:It disables batch mode on rowstore without requiring a change in database compatibility level:

-- 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 в конфигурации уровня базы данных.You can disable batch mode on rowstore via database scoped configuration. Но этот параметр можно переопределить на уровне запроса с помощью указания запроса ALLOW_BATCH_MODE.But you can still override the setting at the query level by using the ALLOW_BATCH_MODE query hint. В следующем примере пакетный режим для данных rowstore включается, несмотря на то что функция отключена через конфигурацию на уровне базы данных:The following example enables batch mode on rowstore even with the feature disabled via database scoped configuration:

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.You can also disable batch mode on rowstore for a specific query by using the DISALLOW_BATCH_MODE query hint. См. следующий пример.See the following example:

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'));

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

Центр производительности для базы данных SQL Azure и ядра СУБД SQL Server Performance Center for SQL Server Database Engine and Azure SQL Database
Руководство по архитектуре обработки запросов Query processing architecture guide
Справочник по логическим и физическим операторам Showplan Showplan logical and physical operators reference
Соединения Joins
Демонстрация адаптивной обработки запросов Demonstrating adaptive query processing
Демонстрация интеллектуальной обработки запросов Demonstrating Intelligent Query Processing