查不到刚执行的存储过程耗时是因为sys.dm_exec_procedure_stats是内存快照，计划被踢出缓存即消失；真正可靠的是查询存储（query store），sql server 2016+需手动启用，支持跨重启、带执行计划和真实耗时。
查不到刚执行的存储过程耗时？别怪 sys.dm_exec_procedure_stats 不靠谱
它不是历史日志，是内存快照——只要计划被踢出缓存（WITH RECOMPILE、内存压力、DBCC FREEPROCCACHE、12 小时无调用），就彻底消失。你刚 EXEC YourProc 完去查，返回空很正常，不代表没跑成功。
真正能跨重启、抗驱逐、带执行计划和真实耗时的，只有查询存储（Query Store）。SQL Server 2016+ 必须开：ALTER DATABASE [YourDB] SET QUERY_STORE = ON;
- 查某过程近一周平均耗时（单位毫秒）：
SELECT p.plan_id, r.avg_duration / 1000.0 AS avg_duration_ms, 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') AND r.last_execution_time > DATEADD(day, -7, GETDATE()); -
avg_duration是微秒，必须除以 1000；默认保留 30 天，可通过STALE_QUERY_THRESHOLD_DAYS调整 - Azure SQL 和 SQL Server 2022 默认启用，老版本得手动开，且至少用 SSMS 16+ 才能图形化配置
没开 Query Store 怎么办？自己埋点写日志表最稳
靠系统视图或工具都不可控，只有写进自己建的 proc_audit_log 表才真正属于你。关键不是“记”，而是“怎么记不拖慢主流程”：
- 开头打点：
DECLARE @start_time datetime2 = SYSDATETIME(); - 结尾算耗时：
DECLARE @duration_ms bigint = DATEDIFF(ms, @start_time, SYSDATETIME()); - 必须用
TRY...CATCH，在CATCH块里也 INSERT 一次失败记录，否则异常退出就断档 - 字段推荐：
proc_name（用OBJECT_NAME(@@PROCID)动态取）、start_time、duration_ms、status（'S'/'F'）、error_msg（ERROR_MESSAGE()截断至 255 字符） - 别在主事务里同步 INSERT 大量日志——加个
TRY...CATCH包裹，失败直接跳过，不中断业务逻辑
实时抓失败和毛刺？用扩展事件（XEvents），别碰 Profiler
SQL Server Profiler 已被微软明确弃用，2026 年起新版本移除。它 Duration 单位混乱（底层微秒但界面常显示错）、开销高、含网络延迟，还不能连 Azure SQL DB。
替代方案是扩展事件，轻量、可控、官方持续支持。监控失败和异常耗时，推荐这两个事件：
-
rpc_completed：捕获所有EXEC调用，加谓词过滤目标过程名，duration字段单位恒为微秒（除以 1000 得毫秒） -
error_reported：捕获错误，配合error_number筛选（如 50000 自定义错误、8134 除零等） - 输出目标必须设为
event_file，别用ring_buffer（重启即丢、容量极小） - 示例创建语句里记得开
collect_statement_text = ON，否则看不到具体是哪条EXEC
MySQL/PostgreSQL 存储过程怎么计时？别用 BENCHMARK()
MySQL 里 BENCHMARK() 是压测函数，不是计时器。它重复执行表达式 N 次，跟单次过程耗时毫无关系。
正确做法：
- MySQL：用
NOW(6)或SYSUTCDATETIME()（8.0.28+），TIMESTAMPDIFF(MICROSECOND, @start, NOW(6))得微秒，除以 1000000 得秒 - PostgreSQL：用
CLOCK_TIMESTAMP()，不是NOW()（后者在事务内固定不变） - 所有数据库都要注意变量作用域——
@start_time必须是局部DECLARE变量，不能用会话级用户变量（@var），否则嵌套调用时值会被覆盖
真正难的不是“怎么记”，而是“记下来之后谁看、怎么看、多久清理”。日志表没分区、没归档策略、没按 proc_name + date 建索引，半年后查一次 WHERE proc_name = 'xxx' 就要 8 秒——那埋点本身就成了性能瓶颈。
