存储过程无法直接explain，需提取内部sql替换变量后单独分析；重点关注type、key、rows三项，确保索引有效、统计信息准确，并优化临时表、json及循环等隐形开销。
存储过程不能直接 EXPLAIN，必须拆出内部 SQL 单独分析
执行 EXPLAIN CALL proc_name() 会报错或返回无效结果——MySQL 不支持对存储过程整体做执行计划分析。真正要盯的，是过程体里那几条关键 SELECT、UPDATE 或带 JOIN 的语句。
操作步骤很直接：
- 用
SHOW CREATE PROCEDURE proc_name查看定义，复制出目标 SQL（尤其注意含WHERE、ORDER BY、GROUP BY的） - 把变量替换成真实值：比如原句是
WHERE user_id = in_uid，测试时得写成WHERE user_id = 12345 - 在语句前加
EXPLAIN执行，别带INTO或游标逻辑，否则无法分析
EXPLAIN 输出里只盯 type、key、rows 这三项
其他字段容易干扰判断，真正决定快慢的就这三个：
-
type是ALL？说明全表扫描，立刻检查WHERE条件列是否建索引，有没有被函数包裹（如WHERE DATE(created_at) = '2026-09-01'） -
key显示NULL或不是你预期的索引名？常见原因是隐式类型转换（比如参数定义为VARCHAR，但字段是BIGINT），或条件用了非最左前缀（INDEX(a,b,c)却只查b = ?） -
rows值远超实际匹配数（比如查 5 行却扫 80 万行）？大概率是统计信息过期，执行ANALYZE TABLE table_name再试
变量传参会让 EXPLAIN 失效，必须代入具体值
在存储过程中写 WHERE id = p_id 然后直接 EXPLAIN，优化器看不到真实值，rows 估算会严重失真，甚至弃用索引走 ALL。
正确做法只有两种：
- 手动替换为真实值再
EXPLAIN，比如WHERE id = 789 - 如果过程里用了
PREPARE + EXECUTE动态拼接，先用SELECT @sql把最终生成的 SQL 打出来，再对它EXPLAIN
别信“加了 FORCE INDEX 就能好”——这只是验证手段，不能当长期解法；根本问题还是让优化器能基于真实值做决策。
别漏掉临时表、JSON、循环这些隐形开销点
它们在 EXPLAIN 里不显眼，但实际耗时可能占大头：
-
CREATE TEMPORARY TABLE默认可能落磁盘，尤其tmp_table_size不够时；可临时调大测试：SET SESSION tmp_table_size = 268435456 - 反复用
JSON_EXTRACT(json_col, '$.status')做条件，比普通字段慢 3–5 倍；建议提前冗余为status VARCHAR(32)并建索引 - 循环里单条
INSERT INTO log VALUES (…)，不如拼成批量：INSERT INTO log VALUES (), (), ()
真正卡住的往往不是“存储过程”这个壳，而是某条没被 EXPLAIN 到的 SQL —— 它可能因为一次未更新的统计信息、一个没覆盖的索引字段，或者一个没加索引的临时表，在后台悄悄吃掉 90% 的时间。
