MySQL不支持EXPLAIN PROCEDURE，因EXPLAIN仅作用于SELECT/UPDATE/DELETE/INSERT等单条查询语句，而存储过程是多语句逻辑容器，优化器按语句而非过程生成执行计划；直接EXPLAIN CALL会报语法错误。
MySQL 8.0 无法直接对存储过程整体执行 EXPLAIN —— 因为存储过程不是单条 SQL，而是多语句封装体；你只能对其中的每条可执行 SQL 单独分析执行计划。
为什么不能直接 EXPLAIN PROCEDURE？
MySQL 的 EXPLAIN 作用对象是「查询语句」（SELECT、UPDATE、DELETE、INSERT），而存储过程本身是服务端逻辑容器，不参与优化器路径选择。优化器只在每次内部 SQL 执行前才生成计划——也就是说，计划是按语句生成的，不是按过程生成的。
常见误解是以为 EXPLAIN + CALL 能生效，但实际会报错：ERROR 1064 (42000): You have an error in your SQL syntax，因为语法根本不支持。
怎么查存储过程中某条 SQL 的执行计划？
核心思路：把存储过程里要分析的 SQL 拆出来，单独加 EXPLAIN 运行。操作时注意三点：
- 复制
BEGIN ... END内的实际语句，去掉变量赋值、IF、LOOP等控制逻辑 - 把过程参数（如
IN user_id INT）替换成具体常量值（如WHERE id = 123），否则EXPLAIN无法估算索引选择性 - 如果语句含游标或临时表，需确认该临时表结构已存在（或先建好同名临时表），否则
EXPLAIN会失败
示例：假设过程中有
SELECT * FROM orders WHERE user_id = p_user_id AND status = 'paid';
就应改写为：
EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';
EXPLAIN ANALYZE 能用在存储过程里吗？
不能直接用，但可以间接验证效果：
-
EXPLAIN ANALYZE会真实执行语句并返回耗时、循环次数等运行时数据，适用于你已提取出的关键 SQL - 它比普通
EXPLAIN更可靠，尤其当表统计信息过期或rows估算严重偏离时 - 注意：它仍只针对单条语句，且执行一次就会产生真实 I/O 和锁，别在生产高峰期对大表乱跑
比如验证上面那条查询的真实性能：
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';
想看整个存储过程的资源消耗怎么办？
用 SET profiling = 1 配合 SHOW PROFILE，但它不等于执行计划——它只告诉你「哪一步花了多少毫秒」，不告诉你「为什么慢」：
-
SET profiling = 1;启用后，每个语句都会被计时记录 -
CALL get_order_summary(123);执行过程 -
SHOW PROFILES;查看所有语句 ID 和总耗时 -
SHOW PROFILE FOR QUERY N;查看第 N 条语句各阶段（比如Creating tmp table、Sorting result）耗时
⚠️ 注意：profiling 在 MySQL 8.0.22+ 已被标记为 deprecated，未来版本会移除；生产环境建议改用 performance_schema 或慢日志分析。
真正容易被忽略的一点：存储过程里反复调用同一段 SQL，但每次传入的参数值差异很大（比如一个查热门用户，一个查冷门用户），会导致执行计划复用失效或误判。这时候光看单次 EXPLAIN 不够，得结合 sys.schema_table_statistics_with_buffer 查实际扫描行数，再比对 rows 字段是否长期严重高估。
