set statistics xml on是sql server中获取存储过程真实执行计划的唯一可靠方式，因ssms“显示实际执行计划”按钮无法穿透set nocount on、动态sql或嵌套调用，必须在新查询窗口首行启用该设置后立即执行存储过程。
SQL Server 中 SET STATISTICS XML ON 是唯一可靠方式
SSMS 界面的“包括实际执行计划”按钮对存储过程基本无效——它无法穿透 SET NOCOUNT ON、EXEC(@sql)、嵌套调用或未执行的分支逻辑。真正拿到参数嗅探后的真实计划，必须手动启用会话级统计：SET STATISTICS XML ON 必须写在调用语句前，且中间不能有 GO 或连接重置。
常见错误包括：在存储过程定义里加 SET STATISTICS XML ON（无效）、先点按钮再执行（捕获不到）、或把 EXEC dbo.proc @p=1 单独执行（脱离原始上下文）。正确做法是新开查询窗口，第一行就写：SET STATISTICS XML ON;，第二行紧接调用语句，例如：EXEC dbo.usp_GetOrderSummary @CustomerID = 123;
MySQL 存储过程不支持整体 EXPLAIN
MySQL 的 EXPLAIN 只作用于单条 DML/SELECT 语句，EXPLAIN CALL proc_name 语法直接报错 ERROR 1064 (42000)。你无法获得“整个过程”的执行计划，只能逐条分析内部 SQL。
实操时需提取关键语句并做三件事：
• 剥离控制逻辑（删掉 IF、DECLARE、游标声明等）
• 将参数替换为具体值（如把 WHERE id = p_id 改成 WHERE id = 123）
• 若涉及临时表，需提前建好同名结构（否则 EXPLAIN 会失败）
例如原过程内有：SELECT * FROM orders WHERE user_id = p_user_id AND status = 'paid';，就应单独运行：EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';
如何验证拿到的是“实际”而非“估计”计划
图形化执行计划里，光看有没有图不够——得盯住三个硬指标：
• 根节点（最左上角 SELECT 或 EXEC）的 ActualRows 和 EstimateRows 数值是否明显不同（相同大概率是估计计划）
• 节点上是否有黄色感叹号图标（表示运行时警告，如隐式转换、缺失统计信息）
• 检查 CachedTime 和 LastExecutionTime 是否与你刚执行的时间接近（避免误读缓存的老计划）
生产环境别长期开着 SET STATISTICS XML ON，它生成大量 XML、拖慢性能。紧急排查可用轻量替代：sp_statement_completed Extended Events + duration > 1000000 过滤，并勾选 query_plan 字段。
Oracle 和 PostgreSQL 的差异点
Oracle 需两步：EXPLAIN PLAN FOR ... 再查 DBMS_XPLAN.DISPLAY，但这是估计计划；要真实计划得用 DBMS_XPLAN.DISPLAY_CURSOR 并传入 sql_id 和 child_number，从 v$sql 里捞最新执行记录。
PostgreSQL 直接 EXPLAIN ANALYZE 就行，但它会真实执行语句——意味着锁、I/O、触发器都会触发，不能随便在生产大表上跑。而 EXPLAIN（无 ANALYZE）只是估算，不执行。
所有数据库都遵循一个底层事实：执行计划按语句生成，不是按过程生成。所谓“存储过程的执行计划”，本质是你拆出来的那条 SQL 在那一刻的真实行为快照——参数值、统计信息、缓存状态，缺一不可。
