Compartir a través de

Almacenamiento en caché del conjunto de resultados

Se aplica a:✅ punto de conexión de análisis SQL y Almacenamiento de datos en Microsoft Fabric

El almacenamiento en caché del conjunto de resultados es una optimización de rendimiento integrada para los endpoints de SQL de Fabric Data Warehouse y Lakehouse que mejora la latencia de lectura.

El almacenamiento en caché del conjunto de resultados funciona conservando los conjuntos de resultados finales para las consultas T-SQL aplicables SELECT , de modo que las ejecuciones posteriores que "alcanzarán" la memoria caché procesarán solo el conjunto de resultados final. Esto puede omitir la compilación compleja y el procesamiento de datos de la consulta original y devolver consultas posteriores más rápido.

Los escenarios de almacenamiento de datos suelen implicar consultas analíticas que procesan grandes cantidades de datos para generar un resultado relativamente pequeño. Por ejemplo, una SELECT consulta que contiene varias combinaciones y realiza lecturas y ordenaciones aleatorias en millones de filas de datos podría dar lugar a una agregación que solo tiene unas pocas filas de longitud. En el caso de cargas de trabajo como informes o paneles que tienden a desencadenar las mismas consultas analíticas repetidamente, el mismo cálculo pesado se puede desencadenar varias veces, aunque el resultado final siga siendo el mismo. El almacenamiento en caché del conjunto de resultados mejora el rendimiento en este escenario y similar para aproximadamente el mismo costo.

Administración automática de la memoria caché

La caché del conjunto de resultados funciona de forma transparente. Una vez habilitado, la creación y reutilización de la memoria caché se aplica de forma oportunista para las consultas.

El almacenamiento en caché del conjunto de resultados se aplica a SELECT las consultas de T-SQL en tablas de almacenamiento, accesos directos a orígenes de OneLake y accesos directos a orígenes que no son de Azure. La administración de la memoria caché se controla automáticamente y se expulsa periódicamente la memoria caché según sea necesario.

Además, a medida que cambian los datos, se garantiza la coherencia de los resultados invalidando la memoria caché creada anteriormente.

Configuración del almacenamiento en caché del conjunto de resultados

El almacenamiento en caché del conjunto de resultados se puede configurar en el nivel de elemento y está habilitado de forma predeterminada para todos los almacenes de Fabric y los puntos de conexión de SQL Analytics de Lakehouse.

Una vez habilitado, se puede deshabilitar en el nivel de elemento o para consultas individuales, si es necesario.

Configuración de nivel de elemento

Utilice el comando T-SQL ALTER DATABASE SET para habilitar el almacenamiento en caché de conjuntos de resultados para un lakehouse o un almacén de datos. Utilice el punto de conexión de SQL Analytics de un Lakehouse para conectarse y ejecutar consultas de T-SQL.

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING ON;

El valor de configuración se puede comprobar en sys.databases, por ejemplo, para ver el valor del contexto actual en Fabric Warehouse o en el endpoint de SQL Analytics de Lakehouse.

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

Para deshabilitar el almacenamiento en caché del conjunto de resultados:

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING OFF;

Configuración de nivel de consulta

Una vez habilitado el almacenamiento en caché del conjunto de resultados en un elemento, se puede deshabilitar para una consulta individual.

Esto puede ser útil para depurar o probar una consulta A/B. Deshabilite el almacenamiento en caché del conjunto de resultados para una consulta mediante la asociación de esta sugerencia al final de SELECT:

OPTION ( USE HINT ('DISABLE_RESULT_SET_CACHE') );

Comprobación del uso de la caché del conjunto de resultados

El uso de la caché del conjunto de resultados se puede comprobar en dos lugares: en el mensaje de salida y en la vista del sistema queryinsights.exec_requests_history.

En la salida del mensaje de una consulta (visible en el Fabric Query Editor o SQL Server Management Studio), la instrucción "Se utilizó la caché del conjunto de resultados" se mostrará después de la ejecución de la consulta si esta pudo usar una caché existente del conjunto de resultados.

Captura de pantalla de los resultados de una consulta que muestra que se usó el almacenamiento en caché del conjunto de resultados.

En queryinsights.exec_requests_history, la columna result_cache_hit muestra un valor que indica el uso de caché del conjunto de resultados para cada ejecución de consulta:

  • 2: la consulta usó la caché del conjunto de resultados (acierto de caché)
  • 1: la consulta creó la memoria caché del conjunto de resultados.
  • 0: la consulta no se aplicaba a la creación o el uso de la memoria caché del conjunto de resultados.

Por ejemplo:

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

Captura de pantalla del editor de consultas de Fabric que muestra una consulta en la vista queryinsights.exec_requests_history.

Habilitar el almacenamiento en caché para el conjunto de resultados

Cuando se emite una SELECT consulta, se evalúa para el almacenamiento en caché del conjunto de resultados. Se deben cumplir varios requisitos para poder crear y usar la memoria caché del conjunto de resultados. Algunas de estas ayudan a mantener el almacenamiento en caché bajo límites internos, algunas ayudan a reservar el almacenamiento en caché para consultas complejas y otras ayudan a mantener la corrección de los resultados en los "aciertos" repetitivos. Un ejemplo obvio es restringir SELECT las consultas con GETDATE() de que sus resultados se almacenen en caché, pero también hay otros casos matizados en los que Fabric decide no almacenar en caché los resultados.

La lista siguiente contiene descalificaciones comunes para el almacenamiento en caché del conjunto de resultados en Fabric Data Warehouse. Si encuentra que una consulta no era aplicable para crear la memoria caché del conjunto de resultados, podría deberse a una o varias de estas razones:

  • El almacenamiento en caché del conjunto de resultados no está habilitado en el elemento al que está conectado actualmente, o está habilitado en el elemento pero la consulta incluyó el indicador DISABLE_RESULT_SET_CACHE.
  • La consulta no es pura SELECT, por ejemplo, CREATE TABLE AS SELECT (CTAS), SELECT-INTO, otro lenguaje de modificación de datos
  • La consulta hace referencia a un objeto del sistema, una tabla temporal, una función de metadatos o no hace referencia a ningún objeto distribuido.
  • La consulta no hace referencia al menos a una tabla de al menos 100 000 filas
  • La consulta hace referencia a un objeto fuera del elemento fabric conectado actualmente (por ejemplo, consulta entre bases de datos)
  • La consulta está dentro de una transacción explícita o un WHILE bucle
  • La salida de la consulta contiene un tipo de datos no admitido y/o el tipo de datos VARCHAR(MAX) y/o el tipo de datos VARBINARY(MAX). Para ver los tipos de datos admitidos, consulte Tipos de datos en Fabric Data Warehouse.
  • La consulta contiene un CAST o CONVERT que tiene alguna referencia al tipo de dato date o sql_variant.
  • La consulta contiene constantes en tiempo de ejecución (como CURRENT_USER o GETDATE())
  • El resultado de la consulta se estima en > 10,000 filas.
  • La consulta contiene funciones integradas no deterministas, funciones de agregado de ventana o funciones ordenadas como PARTITION BY … ORDER BY. Consulte Funciones deterministas y no deterministas.
  • La consulta usa enmascaramiento dinámico de datos, seguridad de nivel de fila u otras características de seguridad
  • La consulta usa el viaje en el tiempo
  • La consulta aplica ORDER BY en una columna o expresión que no se incluye en la salida de la consulta.
  • La consulta se encuentra en una sesión que tiene instrucciones de sesión a nivel de SET con valores no predeterminados (por ejemplo, estableciendo QUOTED_IDENTIFIER en OFF).
  • El sistema alcanzó límites internos para la memoria caché. Los procesos de expulsión de caché en segundo plano liberarán espacio antes de crear la nueva caché.

Estas reglas también se aplican a la reutilización de la memoria caché en ejecuciones posteriores de la misma consulta. Además, es posible que una caché no se use en los escenarios siguientes:

  • Cualquier cambio en las tablas a las que se hace referencia desde que se creó la memoria caché
  • El área de trabajo ha pasado a estar desconectada debido a la creación de una memoria caché, similar a la caché en memoria y en disco.
  • El usuario no tiene permisos suficientes para los objetos de la consulta.
  • La consulta se está llamando desde una conexión de lakehouse o almacén diferente a la desde donde se emitió la consulta original. (Las consultas entre bases de datos no son aptas para el almacenamiento en caché del conjunto de resultados).
  • La consulta usa diferentes columnas de salida, ordenación de columnas o alias que la consulta original.
  • La consulta almacenada en caché no se ha usado en 24 horas

Nota:

Dado que estas calificaciones se evalúan internamente para la mejor aplicación del almacenamiento en caché del conjunto de resultados, es importante tener en cuenta que podrían actualizarse en el futuro.

Contenido relacionado

  • Last updated on