Query Store on Rudi Bruchez

Analyzing the Query Store with an AI agent

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

Co-written with Claude, who ran the lab tests and part of the research.

TL;DR

Searching the Query Store by hand, query by query, takes hours. A command-line agent (Claude Code, Codex) does it on its own if it has sqlcmd and a dedicated login that holds only VIEW DATABASE STATE in each database: it reads the query texts, the plans and the runtime statistics, and gets error 229 on any table. For more caution, DBCC CLONEDATABASE produces a copy without data that contains the Query Store, to restore on another instance.

The Query Store does not keep everything. In AUTO capture mode, an ad hoc query is only recorded from 30 executions or a certain cost onward: in my measurements, a read of the whole Contact.Contact table (120,140 rows) split into 25 queries left no trace. A query run from master or tempdb is recorded nowhere, and a TRUNCATE TABLE never is. The agent only finds what the Query Store kept.

Query Store capture modes

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

Co-written with Claude, who ran the lab tests and part of the research.

TL;DR

In AUTO mode, the default since SQL Server 2019, the Query Store records a query only when it reaches 30 executions, one second of compile CPU or 100 ms of execution CPU. The executions before that point are not counted in the Query Store. Queries inside stored procedures are captured from their first execution, but since SQL Server 2022 cursors are subject to the thresholds, contrary to what the documentation says. ALL records everything, including thousands of ad hoc queries that never run again.

What the Query Store records

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

Co-written with Claude, who ran the lab tests and part of the research.

TL;DR

The Query Store keeps the text, the plans and the runtime statistics of the queries it captures, but not who ran them, nor the parameter values beyond compilation. Even in ALL mode, it sees neither TRUNCATE TABLE, nor CREATE TABLE, nor ALTER TABLE, nor DBCC CHECKTABLE, nor ad hoc queries run from master or tempdb. A query that fails or that the client cancels is recorded, a session ended by KILL leaves only its text and its plan, and a hard shutdown of the instance erases the statistics not yet written to disk.