Query Store on Rudi Bruchez

Les modes de capture du Query Store

Wed, 21 Oct 2026 00:00:00 +0000

Article coécrit avec Claude, qui a mené les tests en laboratoire et une partie des recherches.

TL;DR

En mode AUTO, la valeur par défaut depuis SQL Server 2019, le Query Store n’enregistre une requête qu’au moment où elle atteint 30 exécutions, une seconde de CPU de compilation ou 100 ms de CPU d’exécution. Les exécutions qui précèdent ce moment ne sont pas comptées dans le Query Store. Les requêtes des procédures stockées sont capturées dès la première exécution, mais depuis SQL Server 2022 les curseurs sont soumis aux seuils, contrairement à ce que dit la documentation. ALL enregistre tout, y compris des milliers de requêtes ad hoc jamais relancées.

Ce que le Query Store enregistre

Wed, 21 Oct 2026 00:00:00 +0000

Article coécrit avec Claude, qui a mené les tests en laboratoire et une partie des recherches.

TL;DR

Le Query Store garde le texte, les plans et les statistiques d’exécution des requêtes qu’il capture, mais pas qui les a lancées, ni les valeurs des paramètres au-delà de la compilation. Même en mode ALL, il ne voit ni TRUNCATE TABLE, ni CREATE TABLE, ni ALTER TABLE, ni DBCC CHECKTABLE, ni les requêtes ad hoc lancées depuis master ou tempdb. Une requête en erreur ou annulée par le client est enregistrée, une session tuée par KILL ne laisse que son texte et son plan, et un arrêt brutal de l’instance efface les statistiques qui n’étaient pas encore écrites sur disque.

Analyser le Query Store avec un agent IA

Wed, 21 Oct 2026 00:00:00 +0000

Article coécrit avec Claude, qui a mené les tests en laboratoire et une partie des recherches.

TL;DR

Fouiller le Query Store à la main, requête par requête, prend des heures. Un agent en ligne de commande (Claude Code, Codex) le fait seul s’il dispose de sqlcmd et d’un login dédié qui n’a que VIEW DATABASE STATE dans chaque base : il lit les textes, les plans et les statistiques d’exécution, et reçoit une erreur 229 sur toute table. Pour plus de prudence, DBCC CLONEDATABASE produit une copie sans données qui contient le Query Store, à restaurer sur une autre instance.

Le Query Store ne garde pas tout. En mode de capture AUTO, une requête ad hoc n’est enregistrée qu’à partir de 30 exécutions ou d’un certain coût : dans mes mesures, une lecture de toute la table Contact.Contact (120 140 lignes) découpée en 25 requêtes n’a laissé aucune trace. Une requête lancée depuis master ou tempdb n’est enregistrée nulle part, et un TRUNCATE TABLE jamais. L’agent ne trouve que ce que le Query Store a gardé.