存储过程本身不提速，真正快的是它默认包裹事务+减少网络往返；其优势在于服务端执行规避连接开销，且自动单事务提交，而循环单条INSERT反而更慢。
存储过程本身不提速，真正快的是它默认包裹事务 + 减少网络往返
MySQL 存储过程执行批量插入变快，不是因为“存储过程有魔法”，而是它天然规避了客户端驱动层的常见低效模式。你写一个 INSERT INTO t VALUES (), () 语句，在应用层发过去，和把它塞进存储过程里再调用 CALL insert_batch()，底层 SQL 执行路径几乎一样——差别在上下文。
关键点在于：存储过程默认在服务端执行，绕过了应用层反复建立连接、拼接字符串、逐条 execute() 的开销；而且绝大多数存储过程实现会显式加 BEGIN ... COMMIT，自动把多行插入包进单个事务——而应用层开发者常常忘了关 autocommit 或漏写 START TRANSACTION。
- 应用层单条插入：每行触发一次网络 RTT + 一次 SQL 解析 + 一次 redo log 刷盘（若
innodb_flush_log_at_trx_commit=1） - 存储过程内批量插入：一次调用 → 一次网络往返 → 一次解析 → 一次事务提交 → 一次日志刷盘
- 注意：如果存储过程里用循环 + 单条
INSERT，速度反而更慢——它只是把客户端的低效逻辑搬进了服务端
为什么不能直接在存储过程里写 LOOP + INSERT？
MySQL 存储过程的循环体执行效率极低，尤其是配合 INSERT 时。每次循环迭代都触发一次完整的 DML 路径：行锁获取、索引查找、undo 日志生成、redo 缓冲区写入——这些操作无法批量化，且存储过程解释器本身有额外 CPU 开销。
真正有效的写法是：在存储过程中组装好完整 INSERT INTO t VALUES (...), (...), (...) 字符串，再用 PREPARE + EXECUTE 动态执行。但这受限于 max_allowed_packet，且字符串拼接容易引发内存溢出或 SQL 注入风险（除非严格校验输入）。
- 避免：
WHILE i - 可行但需谨慎：
SET @sql = CONCAT('INSERT INTO t VALUES ', @values_list); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; - 更推荐：存储过程只做事务控制和参数封装，批量数据仍由客户端用
executemany()或LOAD DATA INFILE提供
比存储过程更快的替代方案有哪些？
如果你的目标只是“把一堆数据快速写进 MySQL”，存储过程通常是次优解。它增加了维护复杂度，还掩盖了真正的瓶颈点——比如 innodb_log_file_size 太小导致频繁 checkpoint，或目标表上有 5 个二级索引却没提前 DROP。
-
LOAD DATA INFILE：绕过 SQL 解析层，速度通常是纯 SQL 批量插入的 5–20 倍，但要求文件在数据库服务器本地或启用LOCAL INFILE - 客户端批量绑定（如 Python 的
cursor.executemany()）：复用预处理语句，避免重复解析，同时可控事务边界 - 临时禁用索引与约束：
SET FOREIGN_KEY_CHECKS=0、ALTER TABLE t DISABLE KEYS（仅 MyISAM）、或导入前DROP INDEX再重建 - 调整关键参数：
innodb_buffer_pool_size要够大，innodb_log_file_size建议设为 1–4 GB，innodb_flush_log_at_trx_commit=2可显著提升吞吐（接受断电丢最多 1 秒数据）
容易被忽略的崩溃恢复隐患
很多人调大 innodb_log_file_size 或改 innodb_flush_log_at_trx_commit 后发现写入飞快，却没验证异常重启后能否正常恢复。MySQL 8.0 的崩溃恢复时间与 redo log 总大小强相关——比如总日志容量设到 8 GB，崩溃后可能需要几十秒甚至几分钟回放，期间整个实例不可用。
同样，事务太大（如单事务插 20 万行）会导致 undo log 持久化膨胀，不仅拖慢恢复，还可能卡住 purge 线程，让其他事务的 MVCC 版本清理停滞，最终表现为 SELECT 查询变慢或锁等待超时。
真正稳的批量节奏是：每批 2000–5000 行 + 显式事务 + 插完立刻 COMMIT + 监控 innodb_rows_inserted 和 Innodb_os_log_written 变化率。存储过程在这里只是个容器，别让它背锅。
