WHILE循环单条INSERT必然慢，因每行触发redo日志刷盘、索引更新和锁管理；须分批提交（如每1000行）、调优innodb_flush_log_at_trx_commit与bulk_insert_buffer_size，并禁用非必要索引。
别用纯 WHILE 循环单条 INSERT —— 即使加了事务，每插一行仍触发完整日志刷盘、索引更新和锁管理，100 万行在普通 SSD 上大概率超 15 分钟。真要走存储过程路径，必须分批提交 + 关键参数调优，否则不如直接换方案。
为什么 WHILE + 单条 INSERT 必然慢
不是语法问题，是执行模型反模式：
-
innodb_flush_log_at_trx_commit = 1（默认）下，每次INSERT都强制刷 redo log，I/O 完全串行化 - 没显式事务时，MySQL 自动为每条语句启停事务 → 日志写放大 = 行数 × 2（redo + binlog）
- 存储过程解释执行，无编译优化；
RAND()、NOW()、字符串拼接等都在循环内重复计算 - 目标表若有唯一索引或外键，每行都做约束检查，开销线性增长
必须做的三件事：事务分批 + 参数调优 + 避坑写法
仅靠“加 START TRANSACTION”远远不够，常见错误是包一个大事务或漏掉尾批提交：
- 每 1000 行一提交：
IF i % 1000 = 0 THEN COMMIT; START TRANSACTION;，循环结束后再补一次COMMIT - 临时调低持久性保障：
SET GLOBAL innodb_flush_log_at_trx_commit = 0（仅测试环境；生产慎用） - 增大缓存：
SET SESSION bulk_insert_buffer_size = 1024 * 1024 * 8（8MB），加速索引构建 - 禁用非必要索引：插入前
DROP INDEX，插完再重建（尤其主键自增+唯一键）
示例关键片段：
START TRANSACTION;
WHILE i <= 1000000 DO
INSERT INTO t (a, b) VALUES (i, CONCAT('v', i));
IF i % 1000 = 0 THEN
COMMIT;
START TRANSACTION;
END IF;
SET i = i + 1;
END WHILE;
COMMIT;比存储过程更高效的实际替代方案
存储过程只是“能做”，不是“该做”。百万级数据导入，优先考虑这些路径：
-
LOAD DATA INFILE：本地文件导入，通常 2–5 秒完成，但要求文件可被 MySQL 服务端读取 - 递归 CTE（MySQL 8.0+）：
WITH RECURSIVE nums(n) AS (...)生成序列，配合单条INSERT ... SELECT - 数字辅助表：
INSERT INTO t SELECT ... FROM numbers WHERE n ，稳定且易维护 - 客户端批量拼接：
INSERT INTO t VALUES (),(),()...;（每批 ≤ 1000 行），绕过存储过程解释开销
真正容易被忽略的是：分批提交的粒度不是越小越好——100 行/批反而因事务管理开销上升；也不是越大越好——10 万行/批可能触发 max_binlog_cache_size 错误。1000 是经过验证的平衡点，且与默认 innodb_log_file_size 匹配度最高。
