sys.dm_exec_query_stats 看不到大内存消耗查询，因其仅统计已完成/已取消的缓存计划，而高内存查询常处于运行或阻塞态；需结合 sys.dm_exec_requests（查 granted_query_memory_kb）、sys.dm_os_memory_clerks 等实时视图综合分析。
查 sys.dm_exec_query_stats 时为什么看不到大内存消耗的查询？
因为这个视图只记录已缓存的执行计划，且只统计“已完成”或“已取消”的查询；正在运行、被阻塞、或因内存不足直接失败（如报错 8645）的查询，不会出现在这里。真正吃内存的查询往往卡在等待资源阶段，还没走到“完成统计”这步。
所以不能只盯 sys.dm_exec_query_stats，得配合实时运行态视图一起看。
- 优先查
sys.dm_exec_requests：找status = 'running'或'suspended'且granted_query_memory_kb高的会话 - 用
CROSS APPLY sys.dm_exec_sql_text(sql_handle)提取 SQL 文本，避免只看到sql_handle哈希值 - 注意
granted_query_memory_kb是“已授予”内存，不是“已使用”，但它是最接近真实内存需求的指标
sys.dm_os_memory_clerks 显示 CACHESTORE_SQLCP 占比异常高说明什么？
这代表大量即席（ad-hoc）T-SQL 被反复编译并缓存，每个都占一块独立计划缓存空间，容易引发内存碎片和 stolen memory 上升——也就是本该给缓冲池的数据页缓存，被计划缓存“偷走”了。
典型表现是 sys.dm_os_memory_clerks 中 CACHESTORE_SQLCP 的 single_pages_kb 累计值远超 MEMORYCLERK_SQLBUFFERPOOL，同时 sys.dm_exec_cached_plans 返回数万条记录，但 usecounts 大部分为 1。
- 临时缓解：执行
DBCC FREESYSTEMCACHE ('SQL Plans')清空计划缓存（生产环境慎用） - 长期方案：启用
optimize for ad hoc workloads选项，让首次执行只存计划骨架，重复后才存完整计划 - 检查应用层是否滥用拼接 SQL，应改用参数化查询或存储过程
为什么查 sys.dm_exec_sessions + sys.dm_exec_requests 还是找不到内存大户？
因为有些内存消耗不体现在单个请求上，而是由后台任务或内部组件持续占用，比如：
-
MEMORYCLERK_SOSNODE持续增长：可能有未释放的游标、未关闭的连接、或 CLR 集成泄漏 -
MEMORYCLERK_XE突增：扩展事件会话配置了过大缓冲区或未设置MAX_DISPATCH_LATENCY -
MEMORYCLERK_FULLTEXT异常：全文索引重建中或存在大量待处理的变更跟踪
这时要回到 sys.dm_os_memory_clerks，按 type 分组求和，重点关注 virtual_memory_committed_kb 和 single_pages_kb 两项，再结合 sys.dm_os_sys_memory.available_physical_memory_kb 判断 OS 层是否已开始施压。
执行 SELECT * FROM sys.dm_exec_query_stats 报权限错误怎么办？
这是最常见的权限陷阱。从 SQL Server 2022 开始，访问 sys.dm_exec_query_stats 需要 VIEW SERVER PERFORMANCE STATE 权限，不再是旧版的 VIEW SERVER STATE。
- 检查当前登录名是否有该权限：
SELECT * FROM sys.server_permissions WHERE permission_name = 'VIEW SERVER PERFORMANCE STATE' - 若无，DBA 需执行：
GRANT VIEW SERVER PERFORMANCE STATE TO [login_name] - 切勿用
SELECT *查询 DMV，列结构可能随版本变化；明确写出需要的字段，例如total_grant_kb,total_used_grant_kb,query_hash
真正难定位的内存问题，往往不是某条 SQL 吃得多，而是多个小查询叠加、缓存策略不当、或外部压力传导进来。盯着一个 DMV 往往漏掉关键线索，必须横向比对 dm_exec_requests、dm_os_memory_clerks、dm_os_sys_memory 三者数据才能闭环。
