SQL Server存储过程内存消耗需查sys.dm_os_memory_clerks中MEMORYCLERK_SQLPLAN项，并结合sys.dm_exec_cached_plans按object_id统计plan_count；计划是否存活应通过plan_handle在sys.dm_exec_cached_plans中验证，而非仅依赖sys.dm_exec_procedure_stats；长期监控应启用查询存储（QUERY_STORE）获取avg_query_max_used_memory等真实内存指标。
SQL Server 存储过程的内存消耗怎么看？别只盯 sys.dm_exec_procedure_stats
查 sys.dm_exec_procedure_stats 只能知道“当前还在缓存里的过程”执行了多少次、平均耗时多少，但它不暴露内存占用。真正吃内存的是执行计划本身，不是过程名。计划缓存（MEMORYCLERK_SQLPLAN）在 sys.dm_os_memory_clerks 里才体现得清：
- 先确认缓存总占比：
SELECT type, name, pages_kb FROM sys.dm_os_memory_clerks WHERE type = 'MEMORYCLERK_SQLPLAN' - 再定位具体哪个过程占得多：
SELECT TOP 10 object_name(object_id) AS proc_name, count(*) AS plan_count FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) t WHERE t.objectid IS NOT NULL GROUP BY object_name(object_id) ORDER BY plan_count DESC - 注意：一个存储过程可能有多个不同参数组合生成的计划（即“计划膨胀”），
count(*)高往往意味着没用参数化或存在隐式转换
为什么 DBCC FREEPROCCACHE 不该随便用？
清掉整个计划缓存会导致后续所有查询重编译，CPU 瞬间飙升——尤其 OLTP 环境里，几十个并发 EXEC 同一个过程，会触发几十次编译风暴。
- 真要清理，优先按计划粒度操作：
DBCC FREEPROCCACHE (0x05...)（传具体plan_handle） - 或者按过程名批量清理（SQL Server 2016+）：
DECLARE @plan_handle varbinary(64); SELECT @plan_handle = plan_handle FROM sys.dm_exec_procedure_stats WHERE object_id = OBJECT_ID('YourProc'); DBCC FREEPROCCACHE (@plan_handle); -
DBCC DROPCLEANBUFFERS清的是数据页缓存（Buffer Pool），和执行计划无关，别混用
如何确认某个存储过程的执行计划是否还活着？
想用 sys.dm_exec_query_plan 查计划但返回 NULL，大概率不是权限问题，而是计划已被踢出缓存。验证三步走：
- 查它是否还在
sys.dm_exec_procedure_stats里出现（说明统计信息还在） - 用它的
plan_handle去sys.dm_exec_cached_plans中查是否存在：SELECT * FROM sys.dm_exec_cached_plans WHERE plan_handle = 0x05... - 如果第二步没结果，就确定计划已淘汰；此时
sys.dm_exec_query_plan必然返回NULL，强行关联无意义
长期监控别依赖动态视图，启用查询存储才是正解
sys.dm_exec_procedure_stats 和 sys.dm_exec_cached_plans 全是内存快照，服务重启、内存压力、DBCC FREEPROCCACHE 都会让历史记录归零。SQL Server 2016+ 必须开 QUERY_STORE：
- 启用：
ALTER DATABASE [YourDB] SET QUERY_STORE = ON - 查某过程的历史内存/耗时：
SELECT p.plan_id, r.avg_duration / 1000.0 AS [ms], r.avg_logical_io_reads, r.avg_query_max_used_memory FROM sys.query_store_plan p JOIN sys.query_store_runtime_stats r ON p.plan_id = r.plan_id JOIN sys.query_store_query q ON p.query_id = q.query_id WHERE q.object_id = OBJECT_ID('YourProcName') - 注意：
avg_query_max_used_memory单位是 KB，这才是执行时 SQL Server 实际授予该计划的最大内存
真正容易被忽略的是：计划缓存膨胀往往不是单个存储过程写得差，而是大量相似但参数不同的调用反复生成新计划——比如 WHERE id = 1 和 WHERE id = 2 被当成两个独立语句缓存。这种问题，QUERY_STORE 的 DIGEST 聚合和强制参数化配置才能治本。
