1. Query Store 不是“自动归档器”，而是 SQL Server 的手术级诊断探针
很多人第一次听说 Query Store，是在 Azure SQL DB 控制台里点开“查询性能洞察”时看到的那个蓝色开关。随手一开，等了两天再去看——咦？执行计划变多了，运行时间柱状图也出来了，好像真能“自动监控”似的。于是顺手把它当成数据库的“黑匣子记录仪”，以为只要开着，就能在出问题时回放历史、一键定位慢查询。这种理解，错得非常典型，而且后果很实在：某次生产环境突发 CPU 持续 98%，运维同事翻遍 Query Store 报表，却找不到任何“明显变慢”的语句；最后发现罪魁祸首是一条每天只跑一次、但执行耗时从 3 秒暴涨到 47 秒的报表 SQL——而它在 Query Store 里压根没被采集到。
这不是 Query Store 失灵，而是我们没看懂它的设计哲学：它根本不是为“全量捕获”而生，也不是一个被动日志系统。它是 SQL Server 内核深度嵌入的一套主动式性能观测与决策反馈闭环，其核心目标从来不是“把所有东西都记下来”，而是“在资源可控的前提下，精准捕获对性能决策真正有价值的信号”。这个信号，必须同时满足三个硬性条件：被执行过、触发了编译/重编译、且通过了内部采样阈值筛选。换句话说，Query Store 的每一条记录，背后都是一次真实的执行上下文快照（包括参数化后的文本、实际执行计划、运行时统计、等待类型分布），而不是简单地把 T-SQL 文本存个档。
这就解释了为什么那条“每天一次”的报表 SQL 会消失——它很可能被 SQL Server 判定为“低频低影响”，在内存压力下被优先清理出计划缓存，而 Query Store 的采集动作又严格依赖于计划缓存中的活跃存在。它不抓“冷门语句”，只盯“正在参与性能博弈”的语句。这就像 ICU 里的监护仪，不会记录病人每分钟的呼吸频率，但会对心率突变、血氧骤降、血压飙升这些关键生命体征做毫秒级采样和标记。Query Store 的工作原理，本质上就是一套运行在数据库内核层的、带智能过滤的“性能生命体征监测系统”。
提示：如果你期望 Query Store 能像 Profiler 或 Extended Events 那样无差别捕获所有语句，那从一开始你就选错了工具。它不是数据采集器，而是性能决策支持系统（PDS）。它的价值不在“有没有”，而在“有没有用”。
要真正用好它，你得先放下“开启即有效”的幻想，转而思考三个更本质的问题：它到底在什么时候开始记录？记录的内容里哪些字段是真正决定诊断成败的关键？当它“看起来没记录”时，到底是真的没发生，还是被策略性忽略了？接下来，我们就一层层剥开它的执行脉络，看看这个被 Azure 控制台简化成一个开关的功能，其底层究竟是如何精密咬合运转的。
2. Query Store 的生命周期：从语句执行到数据落盘的七步链路
Query Store 的数据不是凭空生成的，它严格绑定于 SQL Server 查询执行引擎（QE）与查询优化器（QO）的协作流程。理解它的生命周期，是避免误判“为什么没看到我的查询”的前提。整个过程并非线性流水线，而是一个带有状态跃迁、资源仲裁与异步落盘的多阶段闭环。我把它拆解为七个不可跳过的环节，每个环节都对应一个真实可验证的内部行为。
2.1 第一步：语句抵达——解析与参数化（Parse & Parameterization）
一切始于客户端发送的原始 T-SQL。SQL Server 首先进行语法解析（Parse），确认语句结构合法。紧接着进入关键的**强制参数化（Forced Parameterization）或简单参数化（Simple Parameterization）**阶段。这是 Query Store 记录粒度的源头。例如，你执行：
SELECT * FROM Orders WHERE OrderID = 1001; SELECT * FROM Orders WHERE OrderID = 1002;在启用简单参数化后，SQL Server 会将它们统一视为：
SELECT * FROM Orders WHERE OrderID = @0;Query Store 中存储的query_text字段，记录的就是这个参数化后的模板，而非原始字面值。这意味着，所有因不同参数值导致的性能差异，都会被归集到同一个query_id下。这也是为什么你在 Query Store 视图中看到的query_text总是带着@p1,@p2这样的占位符——它不是为了“隐藏”，而是为了“归类”。参数化强度由数据库级别设置PARAMETERIZATION控制，默认为SIMPLE，仅对安全语句自动参数化；设为FORCED则对所有语句强制执行，但会带来额外的编译开销，需谨慎评估。
2.2 第二步：计划生成——优化器决策与计划哈希（Optimization & Plan Hashing）
当参数化后的语句需要执行时，优化器介入。它基于当前统计信息、索引状态、内存配置等，生成一个或多个候选执行计划。每个计划在生成瞬间，会被计算出一个唯一的Query Plan Hash（64 位整数）和Query Hash（64 位整数）。这两个哈希值是 Query Store 区分“相同逻辑查询”与“不同执行路径”的核心标识。
query_hash：对参数化后的 SQL 文本进行哈希，代表“查询意图”。上面两个OrderID查询拥有相同的query_hash。plan_hash：对执行计划的 XML 结构进行哈希，代表“具体执行方式”。如果统计信息更新导致优化器选择了不同的索引，即使query_hash不变，plan_hash也会改变。
Query Store 的sys.query_store_query表按query_hash存储查询元数据，sys.query_store_plan表则按plan_hash存储计划详情。这种分离设计，使得你可以轻松回答：“这个查询意图历史上用过哪些执行计划？”以及“这个执行计划被哪些查询意图复用过？”——这是性能回归分析的基石。
2.3 第三步：执行触发——运行时统计采集（Runtime Statistics Collection）
只有当语句真正被执行（EXECUTE），且该执行计划已存在于计划缓存中时，Query Store 才会启动其最核心的“观测”动作。此时，SQL Server 会在执行引擎的各个关键节点（如扫描运算符、连接运算符、聚合运算符）注入轻量级计数器，实时采集以下维度的运行时统计：
count_executions：本次执行次数（批处理中可能多次）avg_duration_ms,last_duration_ms,min_duration_ms,max_duration_msavg_logical_io_reads,avg_physical_io_reads,avg_clr_timeavg_rowcount,last_rowcountavg_log_bytes_used,avg_tempdb_space_used
这些数据并非在语句执行完毕后才汇总，而是以微秒级精度在执行过程中持续更新。更重要的是，它采集的是实际运行时行为，而非预估。例如，一个预估返回 100 行的 Nested Loop Join，如果实际扫描了 50 万行，avg_logical_io_reads和last_rowcount会如实反映这一巨大偏差。这正是它比执行计划 XML 中的“预估行数”更有诊断价值的原因——它告诉你“世界本来的样子”，而非“模型预测的样子”。
2.4 第四步：数据暂存——内存缓冲区与写入队列（In-Memory Buffering）
采集到的运行时统计并不会立刻写入磁盘。SQL Server 为其分配了一块专用的、大小受QUERY_STORE_MAX_STORAGE_SIZE_MB限制的内存缓冲区（Query Store Buffer）。所有新产生的统计信息，首先以压缩格式写入此缓冲区。这是一个典型的生产者-消费者模型：执行引擎是生产者，后台的Query Store Flush Task是消费者。
这个后台任务并非实时运行，而是以固定间隔（默认约 15 分钟）或当缓冲区使用率达到阈值（约 80%）时被唤醒。它的职责是将缓冲区中累积的统计批次，批量写入到sys.query_store_runtime_stats等系统表中。这意味着，从语句执行结束，到你能在sys.query_store_runtime_stats视图中查到其数据，中间存在一个固有的延迟窗口。这个窗口通常在几分钟内，但绝非“即时”。如果你在执行完一条语句后立刻去查视图，大概率是空的——这不是 Bug，而是设计使然。Azure SQL DB 的托管服务会进一步优化此刷新逻辑，但延迟依然存在。
2.5 第五步：计划捕获——编译事件监听与计划序列化（Plan Capture on Compile）
与运行时统计不同，执行计划的捕获发生在编译时刻，而非执行时刻。每当一个查询首次编译，或因统计信息变更、架构修改、RECOMPILE提示等原因触发重编译时，Query Store 的编译事件监听器就会被触发。此时，它会获取优化器刚刚生成的、完整的 XML 格式执行计划，并将其序列化后存入sys.query_store_plan表。
这里有一个极易被忽略的关键点：Query Store 只捕获“成功编译”的计划，不捕获“编译失败”的错误信息。如果你的语句因为语法错误、对象不存在而编译失败，Query Store 不会留下任何痕迹。它只关心“活下来的计划”。此外，一个查询可以拥有多个plan_id，每个对应一次独立的编译事件。当你在sys.dm_exec_query_stats中看到plan_handle变化时，基本可以断定 Query Store 里已经新增了一条plan_id记录。
2.6 第六步：数据关联——运行时统计与计划的双向绑定（Runtime-Plan Binding）
Query Store 最强大的能力之一，是它能将“运行时发生了什么”与“当时用了哪个计划”精确关联起来。这种关联不是靠时间戳匹配，而是通过一个隐式的、强一致的**绑定键（Binding Key）**实现的。在sys.query_store_runtime_stats表中，每一行都包含plan_id和query_id字段；在sys.query_store_plan表中，每一行也包含对应的plan_id和query_id。SQL Server 在写入时，确保这两张表的plan_id值完全一致。
这意味着，你可以写出这样一条“黄金查询”，直接锁定问题根源：
-- 查找过去24小时内，平均执行时间超过5秒，且使用了特定 plan_id 的所有 query_id SELECT qsq.query_id, qsq.query_text, qsp.plan_id, qsp.is_forced_plan, qsr.avg_duration_ms, qsr.last_execution_time FROM sys.query_store_query AS qsq JOIN sys.query_store_plan AS qsp ON qsq.query_id = qsp.query_id JOIN sys.query_store_runtime_stats AS qsr ON qsp.plan_id = qsr.plan_id WHERE qsr.last_execution_time > DATEADD(HOUR, -24, GETUTCDATE()) AND qsr.avg_duration_ms > 5000 ORDER BY qsr.avg_duration_ms DESC;这条查询之所以可靠，正是因为plan_id是跨表的、不可伪造的唯一纽带。它让你能穿透“语句-计划-性能”的三层迷雾，直达因果链。
2.7 第七步：数据老化——基于策略的自动清理（Auto-Cleanup Policy）
Query Store 不是无限增长的。它内置了一套严格的基于时间与空间的双维度老化策略（Cleanup Policy）。默认情况下，它会保留最近 30 天的数据（STALE_QUERY_THRESHOLD_DAYS = 30），但这个阈值是软性的。真正的清理触发器是存储空间使用率。当 Query Store 占用的磁盘空间达到MAX_STORAGE_SIZE_MB的 90% 时，后台任务会立即启动清理，删除最旧的runtime_stats_interval数据（通常是 1 小时间隔的统计批次），直到空间使用率回落到 80% 以下。
这个机制导致了一个反直觉现象：在负载极高的数据库上，你可能永远看不到“30天前”的数据，因为空间压力太大，老数据被持续覆盖；而在一个几乎不怎么用的测试库，30天的数据可能完整保留。因此，STALE_QUERY_THRESHOLD_DAYS更像是一个“保底承诺”，而非“绝对保证”。在 Azure SQL DB 中，这个最大存储空间是根据服务层级（S0, P1, GP, BC）动态分配的，你无法手动调整MAX_STORAGE_SIZE_MB，只能通过ALTER DATABASE ... SET QUERY_STORE (CLEANUP_POLICY = ...)来修改老化策略，但效果受限于底层配额。
注意：
sys.query_store_wait_stats表（等待统计）的采集是独立于上述七步的，它有自己的采样周期（默认 1 分钟）和存储逻辑。它不绑定单次执行，而是聚合时间段内的等待事件。因此，它不能用来分析单条语句的等待瓶颈，而是用于识别数据库级别的“等待热点”。
3. Query Store 的三大核心表：读懂它们，就等于读懂了性能真相
Query Store 的所有能力，最终都沉淀在三张核心系统视图中：sys.query_store_query、sys.query_store_plan和sys.query_store_runtime_stats。它们不是简单的日志表，而是经过精心设计的、彼此正交又紧密耦合的“性能事实表”。很多用户抱怨 Query Store “数据杂乱”、“看不懂”，根源往往在于没有建立起对这三张表之间关系的清晰心智模型。下面，我用一张真实生产环境的诊断案例，带你逐行解读它们的字段含义与实战价值。
3.1sys.query_store_query：查询意图的“身份证”
这张表是 Query Store 的起点，它定义了“什么是同一个查询”。其核心字段如下：
| 字段名 | 类型 | 含义与实战解读 |
|---|---|---|
query_id | bigint | 查询的唯一 ID。这是所有关联的根。同一query_id下的所有plan_id，都代表该查询意图的不同执行方案。 |
query_hash | binary(8) | 查询文本的哈希值。判断“是否为同一类查询”的金标准。query_hash相同，说明 SQL 逻辑一致（参数化后）。query_hash不同，则一定是不同语句。 |
object_id | int | 关联的数据库对象 ID（如表、视图）。为 NULL 表示是即席查询（Ad-hoc）。这是快速过滤出“业务核心表相关查询”的关键。 |
query_parameterization_type_desc | nvarchar | 参数化类型（USER,SIMPLE,FORCED）。解释为什么你的不同参数语句被归为一类。 |
is_cloumnstore | bit | 是否涉及列存储索引。在分析分析型负载时，这是区分 OLTP 与 OLAP 查询的快捷方式。 |
实战场景还原：某天，DBA 收到告警，SalesReport表的读取延迟飙升。他立刻执行：
SELECT query_id, query_hash, object_id, OBJECT_NAME(object_id) AS object_name, query_parameterization_type_desc FROM sys.query_store_query WHERE object_id = OBJECT_ID('SalesReport');结果返回了 12 行，query_id从 1001 到 1012。这说明，有 12 个不同的查询意图（query_hash各不相同）都在访问SalesReport表。其中query_id = 1005的query_parameterization_type_desc是USER，意味着它使用了sp_executesql并显式传参，而query_id = 1008是SIMPLE，说明是应用层拼接的 SQL。这立刻将排查范围从“一个表的问题”缩小到“12 个具体查询的问题”，并提示了不同的优化路径：对USER类型，重点看参数嗅探；对SIMPLE类型，重点看是否能改用参数化。
3.2sys.query_store_plan：执行计划的“病历档案”
如果说query_store_query是患者姓名，那么sys.query_store_plan就是他的全部病历档案。它记录了每一次“诊断”（编译）的结果。关键字段解析：
| 字段名 | 类型 | 含义与实战解读 |
|---|---|---|
plan_id | bigint | 计划的唯一 ID。这是连接“意图”与“表现”的桥梁。一个query_id可以有多个plan_id，代表历史上的不同治疗方案。 |
query_id | bigint | 外键，指向query_store_query。建立“意图-方案”关系的唯一纽带。 |
plan_hash | binary(8) | 执行计划 XML 的哈希值。判断“是否为同一套执行逻辑”的依据。plan_hash相同，说明执行步骤、算子选择、索引使用完全一致。 |
is_forced_plan | bit | 是否被强制使用（sp_query_store_force_plan）。这是识别“人工干预痕迹”的第一眼。如果为 1，说明 DBA 曾手动固化过此计划，后续性能变化需优先检查此操作。 |
force_failure_count | int | 强制失败次数。当is_forced_plan=1但此值 > 0，说明该计划已失效（如索引被删），强制失败，SQL Server 已自动回退到其他计划。这是“计划强制”功能健康度的晴雨表。 |
last_execution_time | datetime2 | 此计划最后一次被使用的 UTC 时间。快速判断一个“古老计划”是否还在服役。如果last_execution_time是一个月前，而query_id的其他plan_id都是今天，那这个古老计划大概率已被淘汰。 |
实战场景还原：继续上面的SalesReport案例。DBA 发现query_id = 1005的性能在昨天下午 3 点突然恶化。他立刻查：
SELECT plan_id, is_forced_plan, force_failure_count, last_execution_time, query_plan -- XML 计划，可点击展开查看 FROM sys.query_store_plan WHERE query_id = 1005 ORDER BY last_execution_time DESC;结果发现，plan_id = 5001（is_forced_plan = 1）在昨天下午 2:58 被最后一次使用，之后plan_id = 5002（is_forced_plan = 0）开始被大量使用。再查force_failure_count，发现5001的值为 3。这清晰地勾勒出事件链：DBA 昨天上午强制了5001，但下午因统计信息更新，5001失效（force_failure_count增加），SQL Server 自动切换到5002，而5002的执行效率远低于5001。问题根源不是查询本身，而是强制计划的失效与未及时跟进。
3.3sys.query_store_runtime_stats：性能表现的“体检报告”
这是 Query Store 的“结果表”，它告诉你每一个plan_id在实际运行中表现如何。其设计是典型的“宽表+时间分区”模式，每一行代表一个plan_id在一个runtime_stats_interval_id（通常是 1 小时）内的聚合统计。核心字段：
| 字段名 | 类型 | 含义与实战解读 |
|---|---|---|
runtime_stats_id | bigint | 统计记录的唯一 ID。一般无需直接使用。 |
plan_id | bigint | 外键，指向query_store_plan。这是“体检报告”与“病历档案”的绑定键。 |
runtime_stats_interval_id | int | 时间区间 ID。通过sys.query_store_runtime_stats_interval表可查到具体起止时间。这是做“时间序列对比”的基础。 |
avg_duration_ms | float | 平均执行时长（毫秒）。最常被关注的指标，但需结合count_executions看。一个avg_duration_ms=1000的查询，如果count_executions=1，影响微乎其微；如果是count_executions=10000，那就是灾难。 |
avg_logical_io_reads | float | 平均逻辑读页数。比duration更稳定的 I/O 效率指标。它不受锁等待、CPU 竞争等外部因素干扰，纯粹反映数据访问效率。avg_logical_io_reads暴涨，十有八九是索引失效或统计信息陈旧。 |
avg_rowcount | float | 平均返回行数。与执行计划中的“预估行数”对比，是发现参数嗅探（Parameter Sniffing）的最直接证据。如果avg_rowcount波动极大（如从 100 到 100000），而avg_duration_ms也同步剧烈波动，基本可锁定。 |
stdev_duration_ms | float | 执行时长的标准差。衡量性能稳定性的“血压计”。一个avg_duration_ms=500但stdev_duration_ms=450的查询，说明它时快时慢，极不稳定，背后往往是资源争用或计划抖动。 |
实战场景还原：DBA 锁定了plan_id = 5002是罪魁祸首。他现在要深挖5002的“体检报告”：
SELECT qsrsi.start_time, qsrsi.end_time, qsrs.avg_duration_ms, qsrs.avg_logical_io_reads, qsrs.avg_rowcount, qsrs.stdev_duration_ms, qsrs.count_executions FROM sys.query_store_runtime_stats AS qsrs JOIN sys.query_store_runtime_stats_interval AS qsrsi ON qsrs.runtime_stats_interval_id = qsrsi.runtime_stats_interval_id WHERE qsrs.plan_id = 5002 ORDER BY qsrsi.start_time DESC;结果发现，在昨天下午 3 点开始的区间内，avg_logical_io_reads从之前的 2000 暴涨到 150000，而avg_rowcount从 5000 变成了 500000。这完美印证了“统计信息陈旧导致优化器选择了全表扫描”的猜想。他立刻执行UPDATE STATISTICS SalesReport WITH FULLSCAN，一小时后，5002的avg_logical_io_reads回落到 3000，问题解决。
提示：
sys.query_store_wait_stats是第四张重要视图，但它不与plan_id直接绑定，而是按wait_category（如IO,Lock,Latch）和runtime_stats_interval_id聚合。它适合回答“数据库整体在等什么”，但不适合回答“某条 SQL 在等什么”。后者必须回到runtime_stats的avg_duration_ms与avg_logical_io_reads的比值分析。
4. Query Store 的四大陷阱：那些让资深 DBA 也栽跟头的“合理”误判
即便你已熟读官方文档，亲手配置过数十个 Azure SQL DB 实例，Query Store 依然藏着几个极其隐蔽的“认知陷阱”。它们之所以危险，是因为每一个都建立在看似合理的逻辑之上，且在绝大多数常规场景下都能“正常工作”，直到某个临界点被触发，然后悄无声息地给出一个完全错误的结论。我在某次为一家金融客户做性能审计时，就连续踩中其中三个，差点将一个健康的 OLTP 系统诊断为“严重索引缺失”。以下是血泪总结。
4.1 陷阱一：“平均值幻觉”——avg_duration_ms是最危险的数字
这是最高频、最致命的误判。几乎所有人的第一反应都是排序avg_duration_ms，找出最大的那个。但avg_duration_ms是一个被严重污染的指标。它等于total_duration_ms / count_executions。问题在于，count_executions的分母，包含了所有执行，无论成功还是失败，无论超时还是被 kill。
真实案例：一个核心交易查询query_id = 2001，其sys.query_store_runtime_stats显示：
count_executions = 10000total_duration_ms = 5000000（500万毫秒）avg_duration_ms = 500
看起来很健康，500ms 的平均响应。但 DBA 深入查看sys.dm_exec_requests历史，发现这 10000 次执行中，有 9990 次是成功的，平均 10ms；另有 10 次是因死锁被ROLLBACK，每次耗时 500000ms（8分20秒）。5000000 = 9990*10 + 10*500000。所以，avg_duration_ms = 500完全是被那 10 次极端异常值拉高的假象。真实的、对用户体验有影响的 P99 延迟，依然是 10ms。
如何规避：永远不要单独信任avg_duration_ms。必须与stdev_duration_ms和count_executions联合分析。一个健康的查询，stdev_duration_ms应该远小于avg_duration_ms（比如< 0.3 * avg_duration_ms）。如果stdev_duration_ms接近甚至大于avg_duration_ms，说明数据极度离散，此时应直接放弃平均值，转而查询sys.dm_exec_query_stats中的max_elapsed_time，或使用PERCENTILE_CONT函数计算 P95/P99：
-- 计算 P95 执行时长（需 SQL Server 2012+） SELECT PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY avg_duration_ms) OVER (PARTITION BY plan_id) AS p95_duration_ms FROM sys.query_store_runtime_stats WHERE plan_id = 5002;4.2 陷阱二：“计划漂移幻觉”——plan_hash相同，不代表执行路径相同
plan_hash是基于 XML 计划计算的哈希值。理论上，XML 完全一致，plan_hash就一致。但 SQL Server 的执行计划 XML 中，包含一些与执行无关的、动态生成的字段，例如CompileTime、CachedTime、StatementId。这些字段在每次编译时都会变化，导致 XML 不同，从而plan_hash不同。
真实案例：一个报表查询query_id = 3001，在周一和周二各编译了一次。两次的plan_hash不同，sys.query_store_plan中显示为plan_id = 6001和6002。DBA 本能地认为“计划漂移了”，开始对比两个 XML，寻找差异。结果发现，除了CompileTime字段，其他所有算子、索引、连接方式、预估行数都一模一样。这就是典型的“伪漂移”。
如何规避：在对比计划时，永远先忽略CompileTime、CachedTime、StatementId这些元数据字段。可以使用 SQL Server Management Studio (SSMS) 的“比较执行计划”功能，它会自动忽略这些噪声。或者，用 PowerShell 脚本提取 XML 中的<RelOp>节点内容进行哈希，这才是真正反映执行逻辑的“纯净哈希”。
4.3 陷阱三：“冷启动幻觉”——Query Store 在数据库重启后并非“清零”
很多 DBA 认为，数据库服务重启（无论是 Azure SQL DB 的自动维护，还是手动重启），Query Store 的数据会丢失或重置。这是大错特错。Query Store 的数据是持久化存储在数据库文件（.mdf）中的系统表里，与tempdb无关。重启后，所有历史数据完好无损，只是内存中的缓冲区（Buffer）会被清空，新的运行时统计需要重新开始采集。
真实案例：某客户为“彻底解决问题”，在升级后执行了ALTER DATABASE ... SET QUERY_STORE = OFF; ALTER DATABASE ... SET QUERY_STORE = ON;。他以为这会清空所有历史，结果发现sys.query_store_query中的query_id从 10000 开始递增，而不是从 1 开始。他惊恐地发现，“新”的 Query Store 里，query_id居然比“旧”的还大。其实，query_id是一个全局自增的序列号，OFF/ON操作只是停用/启用，不会重置序列。他看到的“10000”，正是上次停用前的最后一个 ID。
如何规避：如果确实需要清空 Query Store（例如，为了排除历史噪音），唯一正确的方法是：
-- 彻底清除所有数据，重置所有 ID ALTER DATABASE [YourDB] SET QUERY_STORE CLEAR;CLEAR命令会物理删除所有 Query Store 表中的数据，并将query_id、plan_id等序列号重置为 1。这是 Azure SQL DB 文档中明确推荐的“重置”操作，而非OFF/ON。
4.4 陷阱四：“强制计划幻觉”——is_forced_plan = 1不代表该计划正在被使用
这是最反直觉的一个。is_forced_plan = 1只表示“这个计划曾被 DBA 强制过”，但它不保证该计划当前有效、可用、或正在被调用。一个被强制的计划，可能因为以下任一原因而失效：
- 其依赖的索引被
DROP； - 其引用的表结构被
ALTER（如列被删）； - 其统计信息严重过期，导致优化器判定其成本过高，拒绝使用；
- 数据库兼容级别被降低，导致某些新算子不可用。
当这些情况发生时，SQL Server 会记录force_failure_count += 1，并在错误日志中写入The query plan for the forced plan 'X' could not be used...，但它不会自动将is_forced_plan设为 0。这个标志位是“只写不读”的，一旦设为 1，就永远是 1，直到你手动sp_query_store_unforce_plan。
真实案例：DBA A 在上周为一个关键查询强制了plan_id = 7001。本周，DBA B 为提升性能，重建了该查询所用的主键索引。7001的计划中硬编码了旧索引的名称，因此失效。force_failure_count变为 5，但is_forced_plan依然是 1。DBA B 查看 Query Store 时，看到is_forced_plan = 1，误以为“计划还在生效”，于是放弃了进一步排查，转而优化其他地方，导致问题拖延了三天。
如何规避：检查强制计划的有效性，必须三步走：
- 查
force_failure_count，若 > 0，立即警惕； - 查
last_execution_time，若远早于当前时间，说明已长期未用； - 手动执行
EXEC sp_query_store_force_plan @query_id = X, @plan_id = Y，观察是否报错。如果报错，说明该计划已彻底失效，必须unforce并让优化器重新生成。
注意：
sys.dm_exec_query_plan动态管理视图（DMV）中也能看到usecounts（使用次数），但这只是内存中的缓存计数，重启即失，且不区分 Query Store 的强制状态。它不能替代sys.query_store_plan中的last_execution_time和force_failure_count。
5. Query Store 的进阶实战：从“看到问题”到“根治问题”的闭环工作流
配置好 Query Store，看到数据，只是万里长征第一步。真正的价值，在于将这些冰冷的数字，转化为可执行、可验证、可度量的性能改进动作。我总结了一套在多个大型 Azure SQL DB 项目中反复验证有效的“五步闭环工作流”，它不追求炫技，而是强调每一步的可落地性与可审计性。这套流程的核心思想是：用 Query Store 的数据驱动决策，用 SQL Server 的原生能力执行修复，用 Query Store 的数据验证效果。整个过程，不需要任何第三方工具。
5.1 第一步：锚定问题域——用query_hash聚焦“真问题”
不要一上来就查avg_duration_ms排名。先问自己：这个问题影响的是谁？是某个核心业务模块？还是整个数据库的稳定性？答案决定了你的切入点。
- 如果是模块级问题（如“订单提交变慢”）：找到该模块所有相关的表（
Orders,OrderItems），然后执行：
-- 找出所有访问这些表的 query_id SELECT DISTINCT qsq.query_id, qsq.query_hash FROM sys.query_store_query AS qsq WHERE qsq.object_id IN ( SELECT object_id FROM sys.objects WHERE name IN ('Orders', 'OrderItems') );得到一个query_hash列表。后续所有分析，都围绕这个列表展开。这避免了被全库的“噪音查询”（如 DBA 的临时诊断语句）干扰。
- 如果是系统级问题（如“CPU 持续 95%”）：这时
query_hash的粒度太细。你应该转向sys.query_store_wait_stats，按wait_category排序，找出wait_category = 'CPU'或'SOS_SCHEDULER_YIELD'的runtime_stats_interval_id，再反查该时间段内avg_cpu_time_ms最高的plan_id。
关键心得：query_hash是 Query Store 的“上帝视角”。它让你能瞬间从“大海捞针”变成“定向打捞”。我见过太多团队花一周时间在sys.dm_exec_requests里抓瞬时快照，却不如用 `query_hash
