query store 默认仅对sql server 2022新数据库启用,需手动开启并设为read_write模式;检查状态用sys.database_query_store_options,启用需alter database set query_store=on (operation_mode=read_write),同时确保数据库非只读且磁盘空间充足。

确认 Query Store 是否已启用并处于 READ_WRITE 模式
SQL Server 2022 默认为新数据库启用 QUERY_STORE,但已有数据库不会自动开启。如果执行监控逻辑时发现 sys.query_store_query 返回空或报错“Query Store is not enabled”,说明它根本没开。
检查方式:
SELECT actual_state_desc, desired_state_desc, readonly_reason FROM sys.database_query_store_options;
若 actual_state_desc 是 OFF 或 READ_ONLY,需先启用:
- 用
ALTER DATABASE SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE)显式设为读写 - 确保数据库不是只读(
is_read_only = 0在sys.databases中) - 注意:若磁盘空间不足或
MAX_STORAGE_SIZE_MB已满,也会自动降级为READ_ONLY
在存储过程中安全查询 Query Store 视图
直接在存储过程中 SELECT 查询存储 DMV(如 sys.query_store_plan)是可行的,但要注意权限和延迟问题。
VIEW DATABASE STATE 权限是最低要求,否则会报错:The user does not have permission to perform this action.
- 授予方式:
GRANT VIEW DATABASE STATE TO [your_user] - 不要在存储过程中用
EXECUTE AS OWNER绕过权限 —— 这会导致计划缓存污染,且无法反映真实调用者的上下文 - Query Store 数据有延迟:默认每
900秒(15 分钟)刷新一次内存中的统计信息到磁盘;若需“近实时”,可调小DATA_FLUSH_INTERVAL_SECONDS(最小支持 30 秒),但会增加 I/O 开销
捕获特定存储过程的查询性能数据
Query Store 不按“存储过程名”聚合,而是按每个独立语句(sql_handle + statement_start_offset)记录。这意味着一个存储过程里多个 SELECT 会被拆成多行。
要定位某存储过程内的慢查询,推荐组合过滤:
- 用
sys.dm_exec_procedure_stats找出该过程最近执行时间、平均耗时等粗粒度指标 - 再关联
sys.query_store_query的object_id字段(等于该过程的object_id)筛选其内部语句 - 注意:
is_natively_compiled = 1的过程需额外调用sys.sp_xtp_control_query_exec_stats启用统计收集,否则运行时数据为空
示例片段(查某个存储过程内最耗 CPU 的语句):
SELECT qsq.query_id, qsq.query_text_id,
qt.query_sql_text,
qsp.avg_cpu_time
FROM sys.query_store_query qsq
JOIN sys.query_store_query_text qt ON qsq.query_text_id = qt.query_text_id
JOIN sys.query_store_plan qsp ON qsq.query_id = qsp.query_id
WHERE qsq.object_id = OBJECT_ID('YourStoredProcedureName');
避免在循环中高频轮询 Query Store 视图
Query Store 视图本身不轻量,尤其带聚合(AVG、GROUP BY)或跨多张表 JOIN 时,容易引发阻塞或资源争用。
常见误用:
- 在 WHILE 循环里每 5 秒查一次
sys.query_store_runtime_stats做“实时监控” —— 这反而成为性能瓶颈 - 未加
WHERE条件直接扫全表,导致大量逻辑读 - 在高并发 OLTP 存储过程中嵌入这类查询,拖慢主业务逻辑
更合理的方式:
- 把 Query Store 查询抽离为单独作业(SQL Agent Job),按分钟级频率汇总写入自定义监控表
- 存储过程里只查缓存结果(如从
tempdb表或内存优化表中读取最新快照) - 真要动态判断,优先用轻量 DMV,例如
sys.dm_exec_requests查当前正在跑的语句,而非回溯 Query Store 历史
Query Store 的核心价值不在“实时响应”,而在“可追溯性”。想靠它做毫秒级决策会失望;但若用于归因某次升级后性能下滑、或复现某条语句的计划退化,它非常可靠 —— 前提是你没在错误的时间点、用错误的方式去查它。










