rpc_completed事件最适合捕获存储过程整体耗时，自带duration字段（微秒），需过滤>1秒并限定数据库；sp_statement_completed用于下钻语句级性能，需开启collect_statement_text且慎用于高并发。
用 rpc_completed 事件抓存储过程级耗时
想看一个 EXEC proc_name 调用整体花了多久，rpc_completed 是最轻量、最直接的入口。它在 RPC（远程过程调用）结束时触发，自带 duration 字段（单位微秒），不依赖执行计划生成，也不受 SET NOCOUNT ON 干扰。
关键点：
- 必须加
WHERE [duration] > 1000000过滤（即 >1 秒），否则高频小过程会刷爆日志 - 限定
database_name = N'YourDB'，避免跨库干扰 -
object_name字段直接给出被调用的存储过程名，比解析statement更可靠 - 别用
sql_batch_completed替代——它捕获的是整个批处理，含多条语句，无法准确定位到单个 SP
用 sp_statement_completed 看过程内部哪句 SQL 拖慢了
如果过程里有多个查询、循环或临时表操作，光看总耗时不够，得下钻到语句级。sp_statement_completed 事件能记录每条 T-SQL 的实际执行时间、逻辑读、CPU 时间等，但要注意它和 rpc_completed 是两个粒度。
实操要点：
- 必须开启
collect_statement_text = ON，否则statement字段为空 -
object_name在该事件里是空的，得靠sql_text或关联sql_handle查原始语句 - 高并发下慎用：每条语句都触发一次，开销比
rpc_completed高得多，建议只在问题复现窗口临时启用 - 若过程内含动态 SQL（
EXEC(@sql)），sql_text显示的是拼接后的字符串，不是原始模板
为什么不能只依赖 duration 字段？
duration 看起来直观，但它包含客户端网络往返、结果集序列化、甚至 SSMS 渲染时间——不是纯服务端执行耗时。尤其当返回大结果集时，duration 可能比 cpu_time 高出数倍。
更可靠的组合是：
-
cpu_time：真实 CPU 占用，排除 I/O 和网络抖动 -
logical_reads：反映数据页访问量，比耗时更能暴露索引缺失或扫描膨胀 -
writes+tempdb_allocations：识别是否因排序、哈希或临时表引发磁盘压力 - 对比
cpu_time和duration差值：若差值持续 >500ms，优先查网络或客户端缓冲设置
容易忽略的权限与部署细节
扩展事件（XEvents）不是开箱即用。常见卡点在权限和配置上：
- 监控账号至少要有
VIEW SERVER STATE权限，仅db_owner不够 - 事件日志默认写入
system_health的环形缓冲区，容量小且自动覆盖；生产环境务必导出到文件目标（FILE），并设好max_file_size和max_rollover_files - 别在会话中手动
START/STOP事件——用AUTO_START = ON配置，避免服务重启后监控中断 - 若用 T-SQL 创建 session，记得禁用
event_counter消费者（它只计数不存数据），否则看不到明细
rpc_completed 和 sp_statement_completed 往往要配合使用：先用前者快速筛出异常调用，再对特定 session_id 和时间窗启用后者下钻。最麻烦的其实是日志归档策略和权限收敛——这两处没配好，监控就只是摆设。 
