存储过程本身不慢，慢的是它调用的SQL；排查需打点定位慢SQL并EXPLAIN分析，注意变量传参、引擎差异、临时表开销及函数导致索引失效等问题。
存储过程本身不慢，慢的是它调用的 SQL
MySQL 存储过程（PROCEDURE）本身几乎不消耗执行时间——它的开销主要来自内部执行的 SELECT、UPDATE、INSERT 等语句。所以“存储过程执行慢”，99% 是里面某条 SQL 在拖后腿，而不是过程语法或变量赋值的问题。
排查路径很直接：
- 在存储过程中每条关键 SQL 前加
SELECT NOW(), 'before query X';打点日志（或用GET DIAGNOSTICS捕获影响行数），定位哪一句卡住 - 把那条 SQL 单独拿出来，在客户端执行
EXPLAIN，重点看type是否为ALL、rows是否远超预期、Extra是否含Using filesort或Using temporary - 注意：存储过程里用到的变量（如
WHERE col = @user_id）可能让优化器无法准确估算行数，导致选错索引；可改用WHERE col = ?配合预编译，或强制加USE INDEX
InnoDB 和 MyISAM 对存储过程内事务/锁行为的影响
存储过程是否支持事务、能否安全并发执行，取决于它操作的表所用的存储引擎，而非过程本身。
-
InnoDB支持事务、行级锁、外键约束，适合带START TRANSACTION/COMMIT的存储过程逻辑；但若过程内写入频繁且未合理控制事务粒度，容易引发锁等待甚至死锁 -
MyISAM不支持事务，所有INSERT/UPDATE都是自动提交，且使用表级锁——一个长耗时的存储过程执行期间，整张表会被锁死，其他会话对这张表的任何写操作都会阻塞 - 混合引擎风险：过程里同时操作
InnoDB和MyISAM表时，事务只能保护前者；一旦回滚，MyISAM表的变更已不可逆，数据一致性断裂
检查当前表引擎：SHOW CREATE TABLE table_name; 或 SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t';
参数传递和临时表导致的隐性性能损耗
存储过程里看似无害的操作，可能在底层触发磁盘 I/O 或内存膨胀。
- 传入大文本参数（如 JSON 字符串）并反复
JSON_EXTRACT，比直接传结构化字段慢 3–5 倍；建议前置解析、拆成多个IN参数或用临时表承载 - 过程内创建临时表（
CREATE TEMPORARY TABLE）默认走磁盘（除非tmp_table_size和max_heap_table_size足够大且数据量小），而磁盘临时表比内存临时表慢一个数量级 - 循环中反复
INSERT INTO temp SELECT ...，不如先拼好批量VALUES再一次性插入；每轮循环都触发一次解析+优化，开销叠加明显
为什么加了索引，存储过程还是没变快？
索引生效的前提是查询条件能被优化器识别并匹配。存储过程里几个常见破坏点：
- 对字段用函数：比如
WHERE DATE(create_time) = '2026-04-15'——DATE()会让索引失效；应改写为WHERE create_time >= '2026-04-15' AND create_time - 隐式类型转换：参数声明为
INT，但传入字符串'123'，MySQL 自动转类型，索引失效；统一用CAST(@var AS SIGNED)显式转换 - 组合索引顺序错位：定义了
INDEX idx_a_b (a,b)，但过程里写WHERE b = ?，该索引完全无法使用；必须满足最左前缀原则
真正容易被忽略的是：存储过程里的 SQL 有时会因“SQL_MODE”不同（比如 STRICT_TRANS_TABLES 关闭时允许隐式截断），导致优化器生成不同的执行计划——同一段代码在测试库快、生产库慢，往往卡在这类环境差异上。
