直接执行set statistics xml on再运行存储过程是获取真实参数嗅探后执行计划的唯一可靠方式，因ssms“显示实际执行计划”按钮无法展开存储过程内部逻辑流，遇set nocount on、动态sql或嵌套调用即失效。
直接执行 SET STATISTICS XML ON 再运行存储过程，是唯一能拿到真实参数嗅探后执行计划的方式。点 SSMS 的“包括实际的执行计划”按钮对大多数存储过程无效——尤其当过程里有 SET NOCOUNT ON、动态 SQL 或嵌套调用时，按钮根本捕获不到根路径。
为什么“显示实际执行计划”按钮经常失效
这个按钮依赖 SQL Server 在语句级注入执行上下文，但存储过程是一个封装单元，SSMS 无法自动展开其内部逻辑流。常见失效场景包括：
- 过程开头有
SET NOCOUNT ON：它会抑制影响行数消息，导致 SSMS 误判执行未完成，跳过计划捕获 - 使用
EXEC(@sql)或sp_executesql动态执行：按钮只捕获外层EXEC proc_name，不进动态语句内部 - 过程内含
IF...ELSE分支且某分支未执行：按钮可能只记录走过的路径，漏掉隐藏慢分支 - 调用其他数据库的存储过程（跨库）：权限或上下文隔离导致计划生成中断
正确获取完整执行计划的实操步骤
必须手动控制会话状态，并确保整个过程被完整解析：
- 在新查询窗口顶部第一行写入：
SET STATISTICS XML ON; - 紧接着写调用语句，例如：
EXEC dbo.usp_GetOrderSummary @CustomerID = 123; - **不要**在中间加
GO或换连接——SET只对当前会话生效 - 执行后，在结果面板切换到“执行计划”标签页，XML 计划会以图形形式呈现
- 若需保存供离线分析，右键图形 → “将执行计划另存为…”，格式选
.sqlplan
如何验证你拿到的是“真实”而非“估计”计划
关键看三处细节，缺一不可：
- 计划根节点（最左上角的 SELECT 或 EXEC 节点）属性中，
ActualRows和EstimateRows数值是否明显不同——若相同，大概率仍是估计计划 - 节点上是否有黄色感叹号图标？有则表示运行时警告，如“缺少统计信息”或“隐式转换”，这是实际执行才暴露的问题
- 检查
CachedTime和LastExecutionTime是否与你本次执行时间接近（查sys.dm_exec_query_plan时比对），避免误读了缓存的老计划
生产环境临时排查的轻量替代方案
长期开着 SET STATISTICS XML ON 会拖慢性能，且生成大量 XML 增加网络和内存压力。紧急时可用更精准的替代：
- 启用 Extended Events 捕获：
sp_statement_completed事件 +WHERE [duration] > 1000000（即 >1 秒），并勾选query_plan字段 - 用
sys.dm_exec_procedure_stats查最近执行的统计，结合sys.dm_exec_sql_text和sys.dm_exec_query_plan关联出对应objectid的计划 - 注意过滤
database_id，否则跨库同名存储过程的objectid会冲突，导致查错计划
最容易被忽略的是：即使拿到了图形计划，也要盯住每个运算符的 Actual Number of Rows 和 Number of Executes。一个嵌套循环被重复执行 5000 次，哪怕单次很快，总量也必然爆炸——这种模式在图形上只是一条线，但数字藏在属性里。
