存储过程本身无执行计划，EXPLAIN对CALL无效；需用SHOW CREATE PROCEDURE提取内部DML语句，替换参数后单独EXPLAIN分析，辅以SHOW PROFILE或Performance Schema定位性能瓶颈。
存储过程本身没有执行计划，EXPLAIN 对 CALL 无效
MySQL 存储过程不是可执行的 SQL 语句，而是服务器端的逻辑容器；EXPLAIN CALL proc_name() 会报错或返回空/无意义结果。真正有执行计划的是它内部的 SELECT、UPDATE、DELETE 等 DML 语句。你必须把它们“拆出来”，单独加 EXPLAIN 才能看到优化器决策。
怎么提取并分析存储过程里的关键 SQL？
先用 SHOW CREATE PROCEDURE proc_name 查看定义，再人工识别出带条件、JOIN、ORDER BY、GROUP BY 的核心语句：
- 把
WHERE col = p_param替换成具体值，比如WHERE user_id = 123 - 跳过动态拼接部分（如
CONCAT(...)+PREPARE），这类语句需先构造出最终 SQL 再EXPLAIN - 若含子查询或 CTE，建议分步
EXPLAIN：先查子查询，再查外层 - 注意字符集/排序规则隐式转换——比如参数是
VARCHAR而字段是TEXT，可能导致索引失效
想看真实执行耗时和资源分布，用 SHOW PROFILE（但仅限临时诊断）
SHOW PROFILE 不是执行计划，但它能告诉你一次 CALL 过程中各阶段花了多少时间，比如：
-
executing：纯 SQL 执行阶段（对应 EXPLAIN 中的 rows/type/Extra） -
Copying to tmp table：说明 GROUP BY 或 DISTINCT 缺少覆盖索引 -
Creating sort index：ORDER BY 没走索引，触发了文件排序 -
Waiting for table metadata lock：被 DDL 或长事务阻塞
启用方式：SET profiling = 1 → CALL your_proc() → SHOW PROFILE FOR QUERY 1。注意：MySQL 8.0 已标记为 deprecated，生产环境别长期开启。
更可靠的方式：用 Performance Schema 实时监控
相比 SHOW PROFILE，Performance Schema 是 MySQL 5.6+ 的正式替代方案，支持持续采集：
- 启用存储过程监控：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE '%stored%'; - 查执行统计：
SELECT OBJECT_NAME, COUNT_STAR, SUM_TIMER_WAIT/1000000000 AS sec FROM performance_schema.events_statements_summary_by_program WHERE OBJECT_TYPE = 'PROCEDURE'; - 它不告诉你“为什么慢”，但能快速定位高频或高耗时的过程，优先分析其内部 SQL
真正卡点往往不在执行计划本身，而在循环逻辑、锁竞争、临时表膨胀或事务设计不合理——这些靠 EXPLAIN 看不出来，得结合 SHOW PROFILE 阶段耗时和业务上下文交叉判断。
