Кэширование результирующего набора

Кэширование результирующих наборов является встроенной оптимизацией производительности для конечных точек SQL-аналитики Fabric Data Warehouse и Lakehouse, которая уменьшает задержку чтения.

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

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

Автоматическое управление кэшем

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

Кэширование результирующих наборов применяется к SELECT запросам T-SQL для таблиц хранилища, ссылкам на источники OneLake и ссылкам на источники, не относящиеся к Azure. Управление кэшем обрабатывается автоматически, регулярно вытесняя кэш по мере необходимости.

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

Настройте кэширование результирующих наборов

Кэширование результирующих наборов настраивается на уровне элемента и включается по умолчанию для всех хранилищ Fabric и конечных точек аналитики SQL Lakehouse.

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

Конфигурация на уровне элемента

Значение параметра можно проверить в sys.database, например, чтобы просмотреть значение текущего контекста в конечной точке аналитики SQL Fabric Warehouse или Lakehouse SQL:

SELECT name, is_result_set_caching_on 
FROM sys.databases
WHERE database_id = db_id();

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

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING OFF;

Конфигурация уровня запроса

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

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

OPTION ( USE HINT ('DISABLE_RESULT_SET_CACHE') );

Проверка использования кэша наборов результатов

Использование кэша результирующих наборов можно проверить в двух местах: выходные данные сообщений и системное представление queryinsights.exec_requests_history.

В выходных данных сообщения запроса (видимых в редакторе запросов Fabric или SQL Server Management Studio) инструкция "Кэш результирующих наборов была использована" будет отображаться после выполнения запроса, если запрос смог использовать существующий кэш результирующих наборов.

В queryinsights.exec_requests_history столбец result_cache_hit отображает значение, указывающее использование кэша результирующих наборов для каждого выполнения запроса:

• 2: запрос использовал кэш результирующих наборов (попадание кэша)
• 1: запрос создал кэш результирующих наборов
• 0: запрос не был применим для создания или использования кэша результирующих наборов

Рассмотрим пример.

SELECT result_cache_hit, command, *
FROM queryinsights.exec_requests_history
ORDER BY submit_time DESC;

Соответствие критериям кэширования результирующих наборов

SELECT Когда запрос выдан, он оценивается для кэширования результирующих наборов. Для создания и использования кэша результирующих наборов необходимо выполнить различные требования. Некоторые из них помогают сохранить хранилище кэша в пределах внутренних ограничений, некоторые помогают зарезервировать кэширование для сложных запросов, а другие помогают поддерживать правильность результатов при повторяющихся "попаданиях". Очевидный пример заключается в SELECT ограничении кэширования результатов запросов, но есть и другие случаи GETDATE(), где Fabric решает не кэшировать результаты.

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

• Кэширование результирующих наборов не включено в текущем подключенном элементе, или оно включено в элементе, но запрос содержал подсказку DISABLE_RESULT_SET_CACHE.
• Запрос не является чистым SELECT, например CREATE TABLE AS SELECT (CTAS), SELECT-INTO, другие языки изменения данных.
• Запрос ссылается на системный объект, временную таблицу, функцию метаданных или не ссылается на распределенные объекты.
• Запрос не ссылается хотя бы на одну таблицу с не менее чем 100 000 строк.
• Запрос ссылается на объект вне текущего подключенного элемента Fabric (например, межбазовый запрос)
• Запрос находится в явной транзакции или цикле WHILE
• Выходные данные запроса содержат неподдерживаемый тип данных и/или тип данных VARCHAR(MAX), и/или тип данных VARBINARY(MAX). Сведения о поддерживаемых типах данных см. в разделе "Типы данных" в хранилище данных Fabric
• Запрос содержит CAST или CONVERT, которые имеют некоторое отношение к типу данных date или sql_variant.
• Запрос содержит константы среды выполнения (например CURRENT_USER , или GETDATE())
• Результат запроса, по оценкам, составляет > 10 000 строк.
• Запрос содержит недетерминированные встроенные функции, агрегатные функции окна или упорядоченные функции, такие как PARTITION BY … ORDER BY. См. детерминированные и недетерминированные функции.
• Запрос использует динамическое маскирование данных, безопасность на уровне строк или другие функции безопасности
• Запрос использует путешествие по времени
• Запрос применяет ORDER BY к столбцу или выражению, не включенному в выходные данные запроса.
• Запрос находится в сеансе, где есть операторы сеанса уровня SET с нестандартными значениями (например, установка QUOTED_IDENTIFIER в OFF).
• Система достигла внутренних ограничений для кэша. Процессы фонового высвобождения кэша освобождают место до создания нового кэша.

Эти правила также применяются к повторному применению кэша при последующих запусках того же запроса. Кроме того, кэш может не использоваться в следующих сценариях:

• Любое изменение ссылочных таблиц после создания кэша
• Рабочая область отключена после создания кэша, аналогично кэшированию дисков и памяти
• У пользователя нет достаточных разрешений для объектов в запросе
• Запрос выполняется через другое соединение хранилища данных или склада, отличное от того, через которое был сделан исходный запрос. (Кросс-базовые запросы не подлежат кэшированию результирующих наборов.)
• Запрос использует различные выходные столбцы, упорядочение столбцов или псевдонимы, отличные от исходного запроса.
• Кэшированный запрос не использовался в течение 24 часов

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

• Кэширование в памяти и диске
• Рекомендации по производительности в хранилище данных Fabric