mysql不支持explain call存储过程，必须拆解内部sql并替换参数后单独explain；需剔除控制语句、处理临时表与游标依赖、按分支分别分析，explain analyze虽更准但会真实执行。
MySQL不支持直接EXPLAIN存储过程
不能对存储过程整体执行 EXPLAIN CALL proc_name，语法根本不存在——MySQL 8.0 报错是 ERROR 1064 (42000): You have an error in your SQL syntax。因为存储过程不是单条查询语句，而是包含变量、控制流、多条SQL的逻辑容器；优化器只在每条可执行SQL（如 SELECT、UPDATE）真正执行前才生成计划，不存在“过程级”执行计划。
必须拆出内部SQL再EXPLAIN
核心动作是：从 SHOW CREATE PROCEDURE proc_name 拿到定义，手动提取目标SQL语句，替换参数为具体值，再加 EXPLAIN 运行。关键点有三个：
- 只保留纯数据操作语句（
SELECT/UPDATE/DELETE/INSERT），删掉DECLARE、IF、WHILE、SET等控制逻辑 - 把形参（如
p_user_id INT）替换成真实常量（如WHERE user_id = 123），否则EXPLAIN无法估算索引选择性，rows值可能严重失真 - 若语句引用了临时表（
CREATE TEMPORARY TABLE），需提前在当前会话中建好同名表并插入测试数据，否则EXPLAIN会报Table 'xxx' doesn't exist
EXPLAIN ANALYZE比普通EXPLAIN更准，但要谨慎用
EXPLAIN ANALYZE 会真实执行语句，返回实际扫描行数、循环次数、I/O耗时等运行时数据，特别适合验证统计信息过期或 rows 严重偏差的场景。但它不是“无害查看”，注意：
- 它仍只作用于单条SQL，不能套在
CALL上 - 会真实加锁、产生I/O、写binlog，别在生产环境对大表乱跑
- 如果原存储过程中该SQL带事务控制（如
START TRANSACTION），EXPLAIN ANALYZE不会继承，需自行判断是否在事务上下文中执行
容易被忽略的细节：临时表和游标影响执行路径
存储过程中若用了游标或嵌套循环，拆出的SQL可能依赖临时中间结果。比如游标遍历后插入临时表，后续查询又基于该临时表——此时单独 EXPLAIN 后续查询会失败，除非你已手动建好结构一致的临时表并填充数据。更隐蔽的是：某些存储过程会在不同分支走不同SQL路径（如 IF status = 'paid' THEN ... ELSE ...），必须按实际业务路径分别提取并分析每条SQL，不能只看一个分支。
