Mise en cache des résultats (version préliminaire)

S’applique à :✅ point de terminaison pour les analyses SQL et entrepôt de données dans Microsoft Fabric

La mise en cache de l'ensemble de résultats (préversion) est une optimisation intégrée des performances pour les interfaces d'analyse de Fabric Data Warehouse et Lakehouse SQL qui améliore la latence de lecture.

La mise en cache du jeu de résultats fonctionne en persistant les jeux de résultats finaux pour les requêtes T-SQL applicables SELECT , afin que les exécutions suivantes qui « atteignent » le cache traitent uniquement le jeu de résultats final. Cela peut contourner la compilation complexe et le traitement des données de la requête d’origine et retourner les requêtes suivantes plus rapidement.

Les scénarios d’entreposage de données impliquent généralement des requêtes analytiques qui traitent de grandes quantités de données pour produire un résultat relativement petit. Par exemple, une SELECT requête qui contient plusieurs jointures et effectue des lectures et des shuffles sur des millions de lignes de données peut entraîner une agrégation qui ne contient que quelques lignes. Pour les charges de travail telles que les rapports ou les tableaux de bord qui ont tendance à déclencher les mêmes requêtes analytiques à plusieurs reprises, le même calcul lourd peut être déclenché plusieurs fois, même si le résultat final reste le même. La mise en cache du jeu de résultats améliore les performances dans ce scénario et des scénarios similaires pour environ le même coût.

Important

Cette fonctionnalité est en version préliminaire.

Gestion automatique du cache

Le cache du jeu de résultats fonctionne de manière transparente. Une fois qu’elle est activée, la création et la réutilisation du cache sont appliquées opportunistiquement pour les requêtes.

La mise en cache des jeux de résultats s’applique aux SELECT requêtes T-SQL sur les tables d’entrepôt, aux raccourcis vers les sources OneLake et aux raccourcis vers des sources non-Azure. La gestion du cache est gérée automatiquement et supprime régulièrement le cache en fonction des besoins.

De plus, à mesure que vos données changent, la cohérence des résultats est assurée en invalidant le cache créé précédemment.

Configurer la mise en cache du jeu de résultats

La mise en cache du jeu de résultats est configurable au niveau de l’élément.

Une fois activé, il peut ensuite être désactivé au niveau de l’élément ou pour des requêtes individuelles, si nécessaire.

Pendant la préversion, la mise en cache du jeu de résultats est désactivée par défaut pour tous les éléments.

Configuration au niveau de l’élément

Utilisez la commande T-SQL ALTER DATABASE SET pour activer la mise en cache des résultats pour un lakehouse ou un entrepôt. Utilisez le point de terminaison d’analytique SQL d’un Lakehouse pour vous connecter et exécuter des requêtes T-SQL.

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING ON;

La valeur de paramètre peut être vérifiée dans sys.databases, par exemple pour afficher la valeur du contexte actuel dans Fabric Warehouse ou le point de terminaison d’analytique SQL Lakehouse :

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

Pour désactiver la mise en cache du jeu de résultats :

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING OFF;

Configuration au niveau des requêtes

Une fois la mise en cache du jeu de résultats activée sur un élément, elle peut être désactivée pour une requête individuelle.

Cela peut être utile pour le débogage ou le test A/B d’une requête. Vous pouvez désactiver la mise en cache du jeu de résultats pour une requête en ajoutant cet indice à la fin du SELECT:

OPTION ( USE HINT ('DISABLE_RESULT_SET_CACHE') );

Vérifier l’utilisation du cache du jeu de résultats

L’utilisation du cache du jeu de résultats peut être vérifiée à deux emplacements : Sortie de message et vue système queryinsights.exec_requests_history.

Dans la sortie du message d’une requête (visible dans l’éditeur de requête Fabric ou SQL Server Management Studio), l’instruction « Cache du jeu de résultats a été utilisé » s’affiche après l’exécution de la requête si la requête a pu utiliser un cache de jeu de résultats existant.

Dans queryinsights.exec_requests_history, la colonne result_cache_hit affiche une valeur indiquant l’utilisation du cache du jeu de résultats pour chaque exécution de requête :

2: la requête a utilisé le cache du jeu de résultats (accès au cache)
1: la requête a créé le cache du jeu de résultats
0: la requête n’était pas applicable à la création ou à l’utilisation du cache du jeu de résultats

Par exemple:

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

Qualifiez pour la mise en cache des ensembles de résultats

Lorsqu’une SELECT requête est émise, on évalue sa pertinence pour la mise en cache du jeu de résultats. Différentes exigences doivent être remplies pour être éligibles à la création et à l’utilisation du cache du jeu de résultats. Certains d’entre eux permettent de conserver le stockage du cache sous des limites internes, d’autres permettent de réserver la mise en cache pour les requêtes complexes, et d’autres aident à maintenir la correction des résultats sur les « accès » répétitifs. Un exemple évident consiste à restreindre les SELECT requêtes dont GETDATE() le résultat ne doit pas être mis en cache, mais il existe d’autres cas nuancés où Fabric décide de ne pas mettre en cache les résultats.

La liste suivante contient des disqualifications courantes pour la mise en cache des ensembles de résultats dans Fabric Data Warehouse. Si vous trouvez qu’une requête n’était pas applicable pour la création du cache du jeu de résultats, cela peut être dû à une ou plusieurs de ces raisons :

La mise en cache du jeu de résultats n’est pas activée sur l’élément actuellement connecté, ou elle est activée sur l’élément, mais la requête incluait l’indicateur DISABLE_RESULT_SET_CACHE
La requête n’est pas pure SELECT, par exemple CREATE TABLE AS SELECT , (CTAS), SELECT-INTO, autre langage de modification de données
La requête référence un objet système, une table temporaire, une fonction de métadonnées ou ne fait référence à aucun objet distribué
La requête ne référence pas au moins une table d’au moins 100 000 lignes
La requête fait référence à un objet en dehors de l’élément Fabric actuellement connecté (par exemple, requête inter-bases de données)
La requête se trouve dans une transaction explicite ou une WHILE boucle
La sortie de requête contient un type de données non pris en charge et/ou le type de données VARCHAR(MAX) et/ou le type de données VARBINARY(MAX). Pour connaître les types de données pris en charge, consultez Les types de données dans Fabric Data Warehouse
La requête contient un CAST ou un CONVERT qui a une référence à date ou au type de données sql_variant.
La requête contient des constantes runtime (telles que CURRENT_USER ou GETDATE())
Le résultat de la requête est estimé à > 10 000 lignes
La requête contient des fonctions intégrées non déterministes, des fonctions d’agrégation de fenêtres ou des fonctions ordonnées comme PARTITION BY … ORDER BY. Voir Fonctions déterministes et non déterministes.
La requête utilise le masquage dynamique des données, la sécurité au niveau des lignes ou d’autres fonctionnalités de sécurité
La requête utilise le voyage temporel
La requête applique ORDER BY sur une colonne ou une expression qui n’est pas incluse dans la sortie de la requête
La requête se trouve dans une session qui a des instructions au niveau de la session pour SET avec des valeurs non par défaut (par exemple, en paramétrant QUOTED_IDENTIFIER sur OFF)
Le système a atteint des limites internes pour le cache. Les processus d’éviction du cache en arrière-plan libèrent de l’espace avant la création du nouveau cache.

Ces règles s’appliquent également à la réutilisation du cache lors des exécutions suivantes de la même requête. En outre, un cache peut ne pas être utilisé dans les scénarios suivants :

Toute modification apportée aux tables référencées depuis la création du cache
L'espace de travail est hors ligne depuis la création d'un cache, similaire à la mise en cache mémoire et sur disque
L’utilisateur ne dispose pas des autorisations suffisantes pour les objets de la requête
La requête est appelée depuis une connexion de lakehouse ou d'entrepôt différente de celle où la requête d'origine a été émise. (Les requêtes inter-bases de données ne sont pas éligibles pour la mise en cache du jeu de résultats.)
La requête utilise différentes colonnes de sortie, ordre des colonnes ou alias que la requête d’origine
La requête mise en cache n’a pas été utilisée en 24 heures

Note

Étant donné que ces qualifications sont évaluées en interne pour optimiser l'application de la mise en cache des ensembles de résultats, il est important de garder à l’esprit qu’elles pourraient être mises à jour à l’avenir.

Rétroaction

Cette page a-t-elle été utile ?

Last updated on 2025-09-16