SQL Server Profiler的Duration字段不可信，因其单位为微秒但默认显示为毫秒导致四舍五入误判，且包含网络往返延迟而非纯执行耗时；推荐改用rpc_completed扩展事件配合object_name过滤和collect_statement_text=ON精准捕获存储过程真实耗时。
SQL Server Profiler 仍能捕获存储过程调用事件，但 Duration 字段不可信、开销高、不兼容 Azure SQL，且 2026 年起将被彻底移除——别把它当监控方案用。
为什么 Duration 在 Profiler 里容易误判
你看到的 Duration 值默认显示为毫秒，但底层单位是微秒；若未手动勾选“以微秒显示持续时间”，工具会四舍五入或截断（比如 9999μs 显示为 0），导致实际耗时被低估甚至归零。更关键的是：RPC:Completed 的 Duration 包含网络往返延迟，不是存储过程在服务器内部的真实执行时间。
-
Duration是全链路耗时（客户端发请求 → SQL Server 执行 → 结果返回客户端） -
CPU字段才反映真实计算消耗，但它可能远小于Duration（比如 I/O 等待拉长总耗时） - 高并发下 Profiler 自身 CPU 占用飙升，可能把生产实例拖慢
想抓真实存储过程耗时，该用哪个 XEvent 事件
用 rpc_completed 事件配合 object_name 谓词过滤，比 sql_batch_completed 更精准——后者捕获整批语句，无法区分同一 BATCH 中多个 EXEC 调用。
- 必须开启
collect_statement_text = ON，否则statement字段为空，无法确认是否命中目标存储过程 -
duration字段单位始终是微秒，直接除以 1000 得毫秒，无需切换显示设置 - 长期监控必须输出到
event_file目标，ring_buffer容量极小且实例重启即清空
Oracle 用户别碰 DBMS_PROFILER 测单次耗时
DBMS_PROFILER 不记录 wall-clock 时间，只采样统计“时间片”和执行次数，算不出某一次 EXEC your_proc 到底花了多少毫秒。真要测单次，得走 v$sql 查 elapsed_time 或用 DBMS_MONITOR 绑定 sql_id。
- 必须重编译存储过程：
ALTER PROCEDURE your_proc COMPILE DEBUG，仅设PLSQL_DEBUG=TRUE无效 - 数据分散在四张表：
PLSQL_PROFILER_RUNS、PLSQL_PROFILER_UNITS、PLSQL_PROFILER_DATA、PLSQL_PROFILER_GRANULARITY，漏查任一都找不到行 - 12c+ 默认禁用该包，且
PLSQL_CODE_TYPE = NATIVE时完全失效
真正难的不是启动工具，而是把 runid、unit_number、line#、total_time 四个字段串起来定位到具体哪一行逻辑拖慢了整体——中间断一环，数据就对不上。
