sql server profiler 已被微软明确弃用，2026年及以后版本将移除；其 duration 值单位易误判、开销高、含网络延迟且不支持 azure sql db，可信度与性能均不如扩展事件（xevents）。
SQL Server Profiler 已被微软明确弃用，2026年及以后的 SQL Server 版本中将移除该功能。不要在新项目中使用它监控存储过程耗时，也不建议在生产环境开启长期跟踪。 它的替代方案是 扩展事件（XEvents），性能开销更低、功能更可控、且官方持续支持。
为什么不能继续用 SQL Server Profiler 查看存储过程执行耗时
你看到的 RPC:Completed 或 SQL:BatchCompleted 事件里确实有 Duration、CPU、Reads 字段，但问题不在“能不能看到”，而在“值是否可信”和“代价是否过高”：
-
Duration在 Profiler 中默认以毫秒显示，但底层单位是微秒；若未在工具 > 选项中勾选“以微秒显示持续时间”，你会误判实际耗时（比如显示 10ms 实际是 10000μs = 10ms，但某些版本四舍五入逻辑会导致 9999μs 显示为 0） - Profiler 是基于
SQL Trace引擎，每个事件都走完整会话上下文捕获路径，在高并发下 CPU 和内存开销陡增，容易拖慢生产实例 - 它不区分“网络往返延迟”和“实际执行时间”——
RPC:Completed的Duration包含客户端发请求到收到响应的全链路，不是纯存储过程体内执行时间 - 连接 Azure SQL 数据库时，会报错
To run a trace against SQL Server, you must be a sysadmin...，其实真实原因是Profiler 不支持 Azure SQL DB，错误提示具有误导性
用扩展事件（XEvents）抓取存储过程真实执行耗时
推荐使用 sp_statement_completed 或 rpc_completed 事件，并限定 object_name 过滤目标存储过程。相比 Profiler，XEvents 支持谓词过滤、内存缓冲、异步写入，对服务器影响小得多。
关键实操点：
- 必须启用
collect_statement_text（默认关闭），否则看不到statement内容，无法确认是不是你关心的那个EXEC GetEmployeeByID -
duration字段单位始终是**微秒**，无需切换显示设置；除以 1000 得毫秒，除以 1e6 得秒 - 避免用
sql_batch_completed：它捕获的是整个批处理（可能含多条语句），无法精确定位单个存储过程体内的耗时 - 若要长期监控，把事件输出到
event_file目标，别用ring_buffer（重启即丢，且容量极小）
简短示例（创建轻量级监控会话）：
CREATE EVENT SESSION [Track_GetEmployeeByID] ON SERVER
ADD EVENT sqlserver.rpc_completed(
WHERE ([object_name]=N'GetEmployeeByID')
AND [database_name]=N'YourDB')
ADD TARGET package0.event_file(SET filename=N'Track_GetEmployeeByID.xel');
ALTER EVENT SESSION [Track_GetEmployeeByID] ON SERVER STATE = START;
哪些场景下仍可能“不得不”用 Profiler（并如何减损）
仅限两类情况：临时排查本地开发机上的偶发超时，或需要重放某次调用做复现。此时必须控制范围，否则极易引发雪崩：
- 禁用所有非必要列：取消勾选
ApplicationName、ClientProcessID、NTUserName等，只留EventClass、StartTime、EndTime、Duration、Reads、Writes、CPU、ObjectName - 加强过滤：在
列筛选器中设置ObjectName等于你的存储过程名，Duration大于 1000000（即 1 秒以上），避免淹没有效信息 - 限制文件大小：设为
5 MB并启用启用文件滚动更新，防止磁盘写满或跟踪失控 - 绝对不要勾选
服务器处理跟踪数据—— 这会让 SQL Server 同步等待 Profiler 消费事件，卡住业务线程
真实耗时永远藏在存储过程内部逻辑里，而不是 RPC 调用边界上。如果你发现 rpc_completed.duration 高但 sp_statement_completed.duration 低，大概率是参数嗅探、锁等待或跨库查询拖慢了入口；如果两者都高，才该深入过程体查执行计划。别让工具替你做归因。
