存储过程慢通常因sql未走索引，应使用explain在相同参数和会话环境下分析关键查询，重点检查type、key和extra字段，并警惕隐式转换、复合索引顺序错位及函数操作导致索引失效。
直接看执行计划，别猜逻辑
存储过程慢，八成不是里面写了多少循环或判断，而是某条 SQL 没走对索引。别急着改过程体，先用 EXPLAIN 把关键查询拎出来单独跑一遍——注意：必须在和存储过程**相同参数值、相同会话环境（如 SQL_MODE、字符集）下执行**，否则执行计划可能完全不同。
重点关注三处：type 是否为 ALL 或 index（全表/全索引扫描）；key 是否为 NULL（根本没用索引）；Extra 里有没有 Using filesort、Using temporary 或 Using where; Using index（后者才是覆盖索引生效）。
常见陷阱：
- 存储过程中拼接的动态 SQL，
EXPLAIN看不到真实执行路径，得把生成后的语句复制出来单独分析 - 参数类型与字段类型不一致，比如传入
'123'查询INT字段，触发隐式转换，key显示用了索引但key_len异常小 - 复合索引顺序错位，例如建了
INDEX idx_a_b (a, b)，但过程里只查WHERE b = ?，该索引完全失效
检查参数传递是否引发隐式转换
存储过程里传参看似干净，但 MySQL 对参数类型的推断很敏感。比如定义 IN p_id VARCHAR(32)，却在 WHERE 中写 WHERE user_id = p_id，而 user_id 是 BIGINT，就会强制转成 CAST(p_id AS SIGNED)，索引直接失效。
验证方法：在存储过程内加 SELECT @p_id := p_id;，再用 EXPLAIN SELECT ... WHERE user_id = @p_id; 对比——如果单独用变量能走索引，但直接用参数不能，基本就是类型不匹配。
实操建议：
- 参数类型尽量与对应字段完全一致，宁可显式
CONVERT(p_id, UNSIGNED)，也不依赖自动转换 - 避免在 WHERE 条件里对字段做函数操作，如
WHERE DATE(create_time) = '2024-01-01'，应改写为WHERE create_time >= '2024-01-01' AND create_time - OR 条件慎用，尤其一边无索引时，整个条件易退化为全表扫描；考虑拆成
UNION ALL
确认统计信息是否过期
即使索引存在、写法正确，rows 预估值远高于实际返回行数（比如查 10 行却预估扫 10 万行），大概率是表统计信息陈旧，优化器误判了数据分布。
运行 ANALYZE TABLE table_name; 更新统计信息，再看 EXPLAIN 的 rows 是否回归合理范围。特别要注意：大表 ANALYZE 可能锁表或耗时较长，生产环境建议配合 innodb_stats_auto_recalc=ON 和足够大的 innodb_stats_persistent_sample_pages。
容易忽略的点：
-
SHOW INDEX FROM table_name查看Cardinality值是否明显偏低（比如远小于总行数），这是统计失准的信号 - 分区表需对每个分区单独
ANALYZE，或启用innodb_stats_include_delete_marked=ON（若用软删除） - 频繁写入的大表，定期
ANALYZE比依赖自动更新更可靠
别忽视存储过程本身的开销
当单条 SQL 执行快，但整个存储过程仍慢，问题可能出在过程结构上。比如循环内反复调用含 SELECT 的子过程、大量临时表创建/销毁、或未加 DETERMINISTIC 标记导致无法缓存结果。
定位手段：
- 用
performance_schema.events_statements_history_long查该过程调用链，看耗时是否集中在某次内部查询或某段逻辑 - 临时注释掉部分逻辑，逐段测试耗时变化；尤其注意游标遍历、重复 INSERT/UPDATE、以及未加 LIMIT 的子查询
- 避免在循环中执行相同 SQL，提取到循环外；用批量 INSERT 替代单行插入
最隐蔽的坑是：存储过程里嵌套调用另一个存储过程，而被调用过程的执行计划被缓存了旧版本——此时 FLUSH PROCEDURE CACHE（MySQL 8.0+）或重启连接可能见效，但根源还是参数绑定或统计信息问题。
