存储过程性能问题通常源于内部sql未走索引、循环单行dml、参数类型不匹配等；应查慢查询日志定位call语句，对关键sql逐条explain分析，避免隐式转换，优先用批量操作替代循环。
查慢查询日志确认是不是存储过程本身慢
很多情况下你以为是存储过程慢，其实是它调用的某条 SELECT 或 UPDATE 没走索引，或者被锁住了。先别急着改逻辑，打开慢查询日志看真实执行时间：
SET GLOBAL slow_query_log = ON;<br>SET GLOBAL long_query_time = 0.1;然后在
slow_log 表或文件里找带 CALL 关键字的记录。注意：如果存储过程里有大量循环 + 单条 INSERT，日志里会刷出几百条相似语句，但真正瓶颈可能只是没批量写入。用 EXPLAIN 套进存储过程里的每条 SQL
存储过程不是黑盒，里面每条可执行 SQL 都能单独 EXPLAIN。常见误区是只对最外层 CALL 做分析，结果一无所获。正确做法是把过程体里关键语句（尤其是带 WHERE、JOIN、子查询的）拎出来，手动补上实际参数值再 EXPLAIN：
EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';重点看
type 是否为 ALL，key 是否用了预期索引，rows 是否远超实际匹配数。如果语句含变量（如 WHERE id = in_id），MySQL 5.7+ 支持用 EXPLAIN FORMAT=TRADITIONAL + 手动替换测试，8.0 可直接用 EXPLAIN ANALYZE 看真实执行路径。避免在循环里做单行 DML 操作
这是存储过程性能杀手榜第一。比如用 WHILE 遍历游标，每次循环只 INSERT INTO log_table VALUES (...) 一条。这种写法在万级数据时极易拖垮性能：
- 每次
INSERT触发一次事务开销（即使没显式START TRANSACTION，默认也是自动提交） - 索引维护、日志刷盘、锁竞争全按行放大
- 游标本身比临时表 + 集合操作慢一个数量级
INSERT ... SELECT 代替循环插入；用临时表存中间结果再一次性关联更新；实在要循环，至少把多条语句包进 START TRANSACTION + COMMIT 块里。检查参数传递和变量作用域引发的隐式转换
存储过程传参类型不匹配，会导致索引失效。例如定义参数为 IN p_user_id VARCHAR(32)，但表字段是 BIGINT，调用时传数字 CALL proc(123)，MySQL 会把字段转成字符串去比对，索引直接失效。同理，声明局部变量时用 DECLARE v_name VARCHAR(10)，但实际存了 15 字符，后续用于 WHERE name = v_name 时可能触发截断或隐式转换。排查方法：
- 用
SHOW CREATE PROCEDURE proc_name核对所有参数和变量类型 - 对比对应表字段类型，确保一致或兼容（如
INT↔BIGINT安全，VARCHAR↔INT危险） - 在关键
WHERE条件后加AND 1=1强制让EXPLAIN显示真实使用的索引
真正卡住的地方，往往不是语法多复杂，而是某次 SELECT 没走索引、某次循环忘了批量、某个参数类型悄悄变了。盯着执行计划和实际日志比猜更管用。
