sys.dm_exec_procedure_stats只能查到当前仍在计划缓存中的存储过程统计，若过程带WITH RECOMPILE、内存压力大、被DBCC FREEPROCCACHE清除、或超12小时未调用，就会消失；真实历史需用Query Store（SQL Server 2016+）或自建日志表。
查 sys.dm_exec_procedure_stats 只能看“还在内存里的”，刚跑完就消失的记录根本不会出现——它不是历史日志，是缓存快照。
为什么 sys.dm_exec_procedure_stats 查不到你刚执行的过程
这个视图只保留「当前仍在计划缓存中」的存储过程统计。以下情况会让过程直接“隐身”：
- 过程定义里加了
WITH RECOMPILE，每次执行都丢弃旧计划、不缓存 - SQL Server 内存压力大，刚编译的计划被自动踢出缓存
- 有人执行过
DBCC FREEPROCCACHE或重启了服务 - 过程执行后 12 小时内没再调用，计划老化被系统释放（默认阈值）
哪怕你 5 秒前手动 EXEC YourProc 成功了，查这个视图返回空，也不代表没执行——只是计划已不在内存。
SQL Server 2016+：用查询存储（Query Store）查真实历史耗时
这是唯一跨重启、抗驱逐、带执行计划和运行时指标的方案。启用后所有执行记录持久化到数据库内：
- 启用：
ALTER DATABASE [YourDB] SET QUERY_STORE = ON - 查某过程平均耗时（单位是微秒，必须除以 1000）：
SELECT p.plan_id, r.avg_duration / 1000.0 AS [avg_duration_ms], r.avg_logical_io_reads, r.last_execution_time 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'); - 默认保留 30 天，可通过
STALE_QUERY_THRESHOLD_DAYS调整
没有查询存储？只能自己埋点写日志表
这是最可控、不依赖外部状态的方式，也是唯一真正属于你的历史记录：
- 开头声明：
DECLARE @start_time datetime2 = SYSDATETIME(); - 结尾计算：
DECLARE @duration_ms bigint = DATEDIFF(ms, @start_time, SYSDATETIME()); - 必须
INSERT到日志表，不能只SELECT输出；推荐字段：proc_name（用OBJECT_NAME(@@PROCID)动态取）、start_time、duration_ms、status、error_msg - 务必放在
TRY...CATCH的CATCH块里补失败记录，否则异常退出就断档
动态管理视图易失，查询存储要版本支持，只有自己写的日志表，才真正留得住每一次执行——而时间戳精度、事务隔离、日志表索引设计、磁盘 I/O 竞争，这些细节才是实际落地时最容易被跳过的坎。
