1. Query Store性能治理全景

在SQL Server的性能治理体系中，Query Store（查询存储）并不是一个孤立的监控工具，而是一套内建于数据库引擎的“查询性能黑匣子”。它持续记录语句、执行计划、运行时统计和计划变更历史，把过去只能靠DMV瞬时快照、Profiler跟踪或第三方工具拼凑的信息，沉淀为可回溯、可对比、可强制干预的数据资产。理解它的定位，关键在于认识到：Query Store解决的不是“现在有没有慢查询”，而是“同一条查询为什么昨天快、今天慢，以及如何让它稳定下来”。

传统性能排查常面临三个痛点：执行计划被优化器因统计信息、参数嗅探或索引变化而重新编译后，旧计划无法复现；DMV只保留当前缓存中的计划，重启或内存压力会清空证据；Extended Events需要提前布控，事后无法补录。Query Store通过异步写入数据库内的系统表，按时间窗口保留计划与统计，使“计划回归”从偶发玄学变成可量化、可定位、可修复的工程问题。

核心价值与适用场景

Query Store的核心价值可归纳为四条主线：计划历史留存，记录每个查询在不同时间点的多个执行计划；运行时统计聚合，按时间间隔汇总持续时间、CPU、逻辑读、物理读、执行次数等指标；计划回归识别，通过对比不同时间段的性能差异，自动或手动发现“同一查询、不同计划、性能骤降”；计划强制，将已验证良好的计划固定下来，抵御优化器再次选错计划。

它特别适用于以下场景：升级兼容性级别或SQL Server版本后出现性能回退；参数嗅探导致同一存储过程在不同参数下计划差异巨大；统计信息更新或索引重建后关键查询变慢；需要为关键业务查询建立性能基线并长期跟踪；以及在没有第三方APM工具的环境中，快速定位“谁在消耗CPU和I/O”。

整体工作流：从采集到干预

Query Store的治理闭环可以概括为“采集—观察—对比—干预—验证”五个阶段，但它并非线性一次性流程，而是随业务负载持续循环。下图展示了Query Store在SQL Server实例中的位置、数据流向以及治理动作之间的关系。

从图中可以看到，Query Store位于引擎与治理动作之间：左侧是产生计划与统计的运行时组件，中间是持久化的证据库，右侧是DBA或开发人员基于证据采取的干预。干预结果会重新进入引擎执行，形成闭环。这个闭环中，最容易被忽视的是“验证”环节——强制计划后必须持续观察运行时统计，确认指标确实恢复，而不是仅凭一次执行就下结论。

关键配置与观察入口

启用Query Store的基本语句如下，其中OPERATION_MODE建议生产环境使用READ_WRITE，INTERVAL_LENGTH_MINUTES控制统计聚合粒度，默认60分钟，排查短时抖动时可临时调整为5或10分钟：

ALTER DATABASE [SalesDB]
SET QUERY_STORE = ON
(
    OPERATION_MODE = READ_WRITE,
    CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30),
    DATA_FLUSH_INTERVAL_SECONDS = 900,
    INTERVAL_LENGTH_MINUTES = 60,
    MAX_STORAGE_SIZE_MB = 1024,
    QUERY_CAPTURE_MODE = AUTO,
    SIZE_BASED_CLEANUP_MODE = AUTO
);

启用后，可通过以下目录视图快速观察：sys.query_store_query查看查询文本与上下文；sys.query_store_plan查看计划及强制状态；sys.query_store_runtime_stats按时间间隔查看持续时间、CPU、逻辑读等聚合值；sys.query_store_wait_stats查看等待类别分布。SQL Server Management Studio中右键数据库选择“Query Store”面板，可图形化查看“回归查询”“总体资源消耗”“等待统计”等内置报表。

治理视角下的定位总结

把Query Store放进整个SQL Server性能治理工具箱来看：DMV回答“当前缓存里有什么”，Extended Events回答“刚才发生了什么”，而Query Store回答“过去一段时间内，同一查询的计划与性能如何演变”。它不替代索引优化、查询重写和硬件扩容，但它让这些工作有了可验证的基线。没有Query Store时，一次计划回归可能需要数小时甚至数天才能定位；有了它，通常几分钟内就能锁定问题查询、对比计划差异并实施强制。这正是它在现代SQL Server性能治理中不可替代的位置。