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

• 04/23/2019
• Время чтения: 25 мин
• • 
  • 

ОБЛАСТЬ ПРИМЕНЕНИЯ: SQL Server База данных SQL AzureХранилище данных SQL AzureParallel Data WarehouseAPPLIES TO: SQL Server Azure SQL Database Azure SQL Data Warehouse Parallel Data Warehouse

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

Рабочие нагрузки можно автоматически сделать подходящими для интеллектуальной обработки запросов, включив для базы данных соответствующий уровень совместимости.You can make workloads automatically eligible for intelligent query processing by enabling the applicable database compatibility level for the database. Это можно сделать с помощью Transact-SQL.You can set this using Transact-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.

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

Эта функция позволяет динамически переключить ваш план на лучшую стратегию соединения во время выполнения, используя отдельный кэшированный план.With this feature, your plan can dynamically switch to a better join strategy during execution by using a single cached plan.

Функция адаптивных соединений в пакетном режиме позволяет отложить выбор метода хэш-соединения или соединения вложенными циклами до завершения сканирования первых входных данных.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. Оператор адаптивного соединения определяет пороговое значение, по которому принимается решение о переключении на план вложенного цикла.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. Это работает следующим образом:Here's how it works:

• Если число строк во входных данных соединения сборки настолько мало, что соединение вложенными циклами будет эффективнее хэш-соединения, ваш план переключается на алгоритм вложенных циклов.If the row count of the build join input is small enough that a nested loop join would be more optimal than a Hash Join, your plan switches to a Nested Loops algorithm.
• Если число строк во входных данных соединения сборки превышает пороговое значение, переключение не выполняется и план продолжает использовать хэш-соединение.If the build join input exceeds a specific row count threshold, no switch occurs and your plan continues with a Hash Join.

Следующий запрос используется в качестве наглядного примера адаптивного соединения:The following query is used to illustrate an Adaptive Join example:

SELECT [fo].[Order Key], [si].[Lead Time Days], [fo].[Quantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Dimension].[Stock Item] AS [si]
       ON [fo].[Stock Item Key] = [si].[Stock Item Key]
WHERE [fo].[Quantity] = 360;

Этот запрос возвращает 336 строк.The query returns 336 rows. Включив статистику активных запросов, мы видим следующий план:Enabling Live Query Statistics, we see the following plan:

В плане мы видим следующее:In the plan, we see the following:

1. Просмотр индекса columnstore, используемый для предоставления строк для этапа сборки хэш-соединения.We have a columnstore index scan used to provide rows for the hash join build phase.
2. Новый оператор адаптивного соединения.We have the new Adaptive Join operator. Он определяет пороговое значение, по которому принимается решение о переключении на план вложенного цикла.This operator defines a threshold that is used to decide when to switch to a Nested Loops plan. В нашем примере пороговое значение равно 78 строкам.For our example, the threshold is 78 rows. Если число строк > = 78, будет использоваться хэш-соединение.Anything with >= 78 rows will use a Hash Join. При значении меньше порогового будет использоваться соединение вложенными циклами.If less than the threshold, a Nested Loops Join will be used.
3. Так как мы возвращаем 336 строк, пороговое значение превышено, и поэтому вторая ветвь представляет пробный этап стандартной операции хэш-соединения.Since we return 336 rows, we are exceeding the threshold and so the second branch represents the probe phase of a standard Hash Join operation. Обратите внимание, что статистика активных запросов показывает строки, передаваемые через операторы — в данном случае это "672 из 672".Notice that Live Query Statistics shows rows flowing through the operators - in this case "672 of 672".
4. И последней ветвью является поиск кластеризованного индекса, используемый соединением вложенными циклами в случае, если пороговое значение не было превышено.And the last branch is our Clustered Index Seek for use by the nested loop join had the threshold not been exceeded. Обратите внимание, что мы видим число строк "0 из 336" (ветвь не используется).Notice that we see "0 of 336" rows displayed (the branch is unused).

Теперь давайте сравним план с таким же запросом, но на этот раз для значения Quantity, имеющего всего одну строку в таблице:Now contrast the plan with the same query, but this time for a Quantity value that only has one row in the table:

SELECT [fo].[Order Key], [si].[Lead Time Days], [fo].[Quantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Dimension].[Stock Item] AS [si]
       ON [fo].[Stock Item Key] = [si].[Stock Item Key]
WHERE [fo].[Quantity] = 361;

Запрос возвращает одну строку.The query returns one row. Включив статистику активных запросов, мы видим следующий план:Enabling Live Query Statistics we see the following plan:

В плане мы видим следующее:In the plan, we see the following:

• При возврате одной строки видно, что теперь через поиск кластеризованного индекса передаются строки.With one row returned, the Clustered Index Seek now has rows flowing through it.
• А так как этап сборки хэш-соединения не продолжается, никакие строки через вторую ветвь не передаются.And since the Hash Join build phase did not continue, there are no rows flowing through the second branch.

Преимущества адаптивных соединенийAdaptive Join benefits

Наиболее полезной эта функция будет для рабочих нагрузок с частыми переключениями между просмотрами входных данных мелких и крупных соединений.Workloads with frequent oscillations between small and large join input scans will benefit most from this feature.

Издержки адаптивных соединенийAdaptive Join overhead

Адаптивные соединения предъявляют более высокие требования к памяти, чем эквивалентный план соединения вложенными циклами индекса.Adaptive joins introduce a higher memory requirement than an indexed Nested Loops Join equivalent plan. Дополнительная память запрашивается так, как если бы вложенный цикл был хэш-соединением.The additional memory is requested as if the Nested Loops was a Hash Join. Существуют также издержки на этапе сборки, такие как стартстопная операция и эквивалентное потоковое соединение вложенными циклами.There is also overhead for the build phase as a stop-and-go operation versus a Nested Loops streaming equivalent join. Эти дополнительные затраты обеспечивают гибкость для сценариев, где количество строк во входных данных сборки может меняться.With that additional cost comes flexibility for scenarios where row counts may fluctuate in the build input.

Кэширование и повторное использование адаптивных соединенийAdaptive Join caching and re-use

Адаптивные соединения в пакетном режиме используются для первого выполнения инструкции, а после компиляции последовательные выполнения остаются адаптивными с учетом порога скомпилированных адаптивных соединений и строк времени выполнения, передаваемых через этап сборки внешних входных данных.Batch mode Adaptive Joins work for the initial execution of a statement, and once compiled, consecutive executions will remain adaptive based on the compiled Adaptive Join threshold and the runtime rows flowing through the build phase of the outer input.

Отслеживание операций адаптивного соединенияTracking Adaptive Join activity

Оператор адаптивного соединения имеет следующие атрибуты оператора плана:The Adaptive Join operator has the following plan operator attributes:

Предполагаемый план показывает форму плана адаптивного соединения, а также определенное пороговое значение адаптивного соединения и предполагаемый тип соединения.The estimated plan shows the Adaptive Join plan shape, along with a defined Adaptive Join threshold and estimated join type.

Взаимодействие адаптивного соединения и хранилища запросовAdaptive join and Query Store interoperability

Хранилище запросов захватывает и может принудительно применить план адаптивного соединения в пакетном режиме.Query Store captures and is able to force a batch mode Adaptive Join plan.

Допустимые инструкции адаптивного соединенияAdaptive join eligible statements

Чтобы логическое соединение стало допустимым для адаптивного соединения в пакетном режиме, должны выполняться следующие условия:A few conditions make a logical join eligible for a batch mode Adaptive Join:

• Уровень совместимости базы данных равен 140.The database compatibility level is 140.
• Запрос является инструкцией SELECT (инструкции для изменения данных сейчас недопустимы).The query is a SELECT statement (data modification statements are currently ineligible).
• Соединение может выполняться посредством как индексированного соединения вложенными циклами, так и физического алгоритма хэш-соединения.The join is eligible to be executed both by an indexed Nested Loops Join or a Hash Join physical algorithm.
• Хэш-соединение использует пакетный режим — либо в результате присутствия индекса columnstore во всем запросе в целом, либо из-за того, что на таблицу индекса columnstore ссылается само соединение.The Hash Join uses batch mode - either through the presence of a Columnstore index in the query overall or a Columnstore indexed table being referenced directly by the join.
• Созданные альтернативные решения соединения вложенными циклами и хэш-соединения должны иметь одинаковый первый дочерний элемент (внешняя ссылка).The generated alternative solutions of the Nested Loops Join and Hash Join should have the same first child (outer reference).

Адаптивные соединения и эффективность вложенного циклаAdaptive joins and nested loop efficiency

Если адаптивное соединение переключается на режим вложенного цикла, оно использует строки, уже считанные сборкой хэш-соединения.If an Adaptive Join switches to a Nested Loops operation, it uses the rows already read by the Hash Join build. Этот оператор не считывает повторно строки по внешней ссылке.The operator does not re-read the outer reference rows again.

Строки адаптивного порогового значенияAdaptive threshold rows

Приведенная ниже диаграмма показывает пример пересечения между затратами хэш-соединения и затраты альтернативного ему соединения вложенными циклами.The following chart shows an example intersection between the cost of a Hash Join versus the cost of a Nested Loops Join alternative.? В этой точке пересечения определяется пороговое значение, что, в свою очередь, определяет фактический алгоритм, используемый для операции соединения.At this intersection point, the threshold is determined that in turn determines the actual algorithm used for the join operation.

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

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

ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_BATCH_MODE_ADAPTIVE_JOINS = ON;

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

ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_BATCH_MODE_ADAPTIVE_JOINS = OFF;

Вы также можете отключить адаптивные соединения для определенного запроса, назначив DISABLE_BATCH_MODE_ADAPTIVE_JOINS в качестве указания запроса USE HINT.You can also disable adaptive joins for a specific query by designating DISABLE_BATCH_MODE_ADAPTIVE_JOINS as a USE HINT query hint. Пример:For example:

SELECT s.CustomerID,
       s.CustomerName,
       sc.CustomerCategoryName
FROM Sales.Customers AS s
LEFT OUTER JOIN Sales.CustomerCategories AS sc
       ON s.CustomerCategoryID = sc.CustomerCategoryID
OPTION (USE HINT('DISABLE_BATCH_MODE_ADAPTIVE_JOINS')); 

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

Обратная связь по временно предоставляемому буферу памяти в пакетном режиме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:

ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK = ON;

Когда этот параметр включен, он будет иметь соответствующее состояние в представлении 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:

ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK = OFF;

Вы также можете отключить сброс данных во временно предоставляемый буфер памяти в пакетном режиме для определенного запроса, назначив 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 AzureAzure SQL Database в общедоступной предварительной версииApplies to: База данных SQL AzureAzure SQL Database as a public preview feature

Обратная связь с временно предоставляемым буфером памяти в строковом режиме — это расширение функции обратной связи с временно предоставляемым буфером памяти в пакетном режиме путем настройки размеров временно предоставляемого буфера памяти для операторов пакетного и строкового режимов.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 the public preview of 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:

Отключение сброса данных во временно предоставляемый буфер памяти в строчном режиме без изменения уровня совместимости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:

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

Чтобы разрешить выполнению с чередованием пересматривать оценки кратности 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:

ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

Когда этот параметр включен, он будет иметь соответствующее состояние в представлении 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:

ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

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

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

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

Вы можете включить отложенную компиляцию табличных переменных в Базе данных SQL Azure в режиме общедоступной предварительной версии.You can enable the public preview of table variable deferred compilation in Azure SQL Database. Для этого включите уровень совместимости 150 для той базы данных, к которой вы подключаетесь при выполнении нужного запроса.To do that, enable compatibility level 150 for the database you're connected to when you run the query.

См. дополнительные сведения об отложенной компиляции табличных переменных.For more information, see Table variable deferred compilation.

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

Функция встраивания скалярных определяемых пользователем функций позволяет автоматически преобразовать скалярные определяемые пользовательские функции в реляционные выражения.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

Приблизительная обработка запросов — это новое семейство функций.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

Пакетный режим для данных 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, которые сжаты с использованием кодирования по длине серий.We also process columnstore data that's compressed by using run-length encoding much more efficiently with batch mode joins and batch mode aggregates.

Эти две функции можно использовать независимо друг от друга.The two features are independently usable:

• Можно создать план со строковым режимом, который использует индексы columnstore.You get row mode plans that use columnstore indexes.
• Можно создать план с пакетным режимом, который использует только индексы rowstore.You 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 aren't a good option for some applications. Приложение может использовать другие функции, которые не совместимы с индексами columnstore.An application might use some other feature that isn't supported with columnstore indexes. Например, изменения на месте не совместимы со сжатием columnstore.For example, in-place modifications aren't compatible with columnstore compression. Поэтому таблицы с кластеризованными индексами columnstore не поддерживают триггеры.So triggers aren't supported on tables with clustered columnstore indexes. Что еще важнее, индексы columnstore повышают затраты на выполнение инструкций DELETE и UPDATE.More important, columnstore indexes add overhead for DELETE and UPDATE statements.

Для некоторых гибридных транзакционно-аналитических рабочих нагрузок издержки на транзакционные аспекты рабочей нагрузки перевешивают преимущество от использования индексов columnstore.For some hybrid transactional-analytical workloads, the overhead on a workload's transactional aspects outweighs the benefits of columnstore indexes. В таких сценариях показатель использования ЦП можно снизить, отдельно применяя режим пакетной обработки.Such scenarios can improve CPU use from batch mode processing alone. Поэтому функция "Пакетный режим для данных rowstore" позволяет применять пакетный режим для всех запросов.That's why the batch mode on rowstore feature considers batch mode for all queries. При этом неважно, какие индексы используются.It doesn't matter which 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, we still recommend that you consider a columnstore index, if 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?What changes with batch mode on rowstore?

Помимо перехода на уровень совместимости 150, с вашей стороны не требуется никаких изменений для применения пакетного режима к данным rowstore для рабочих нагрузок.Other than moving to compatibility level 150, you don't have to change anything on your side to enable batch mode on rowstore for candidate workloads.

Даже если запрос не содержит таблиц с индексом columnstore, обработчик запросов теперь включает пакетный режим в эвристический анализ.Even if a query doesn't 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 QP