如何分析SQL存储过程执行频率_基于系统视图的统计分析

sys.dm_exec_procedure_stats常看不到存储过程因其仅显示自SQL Server启动或缓存清除后仍在缓存中且执行过的存储过程WITH RECOMPILE、内存压力致计划被驱逐、权限不足或缓存重置均会导致缺失。查 sys.dm_exec_procedure_stats 为什么经常看不到你的存储过程因为这个视图只保留「自上次 SQL Server 启动或计划缓存被清除后」有执行过且仍驻留在缓存中的存储过程统计。如果过程刚创建、执行完就被踢出缓存比如内存压力大或者用 WITH RECOMPILE 执行不缓存执行计划它就不会出现在这里。确认是否真没执行先在业务时段手动调一次 EXEC your_proc再立刻查视图检查缓存是否被清空过运行 DBCC FREEPROCCACHE 后所有记录都会消失系统重启、故障转移、AG 切换都会重置该视图的计数器注意权限需要 VIEW SERVER STATE 权限否则返回空结果怎么区分「高频但低耗」和「低频但高耗」的过程单看 execution_count 容易误判。真正影响系统的往往是平均每次执行耗时长、逻辑读多、或总 CPU 消耗高的过程——哪怕一天只跑几次。优先排序字段建议total_logical_reads / execution_count平均逻辑读、(total_worker_time / execution_count) / 1000.0平均 CPU 毫秒过滤掉测试/维护类过程加 WHERE object_name(object_id, database_id) NOT LIKE sp_% AND object_name(object_id, database_id) NOT LIKE usp_%_test%last_execution_time 比 cached_time 更能反映真实活跃度后者只是计划加载时间为什么 sys.dm_exec_procedure_stats 的时间单位是微秒SQL Server 内部所有时间统计total_elapsed_time、total_worker_time 等都以微秒μs为单位存储直接除以 1000 得毫秒除以 1000000 得秒。不转换单位就看数值会严重误估耗时。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能