while循环逐条insert极慢因autocommit=on导致每行独立事务，需重复刷盘、解析、校验、更新索引；应改用start transaction+分批提交（如1000行/批），显式控制事务边界并补全末次commit。
WHILE循环逐条INSERT为什么慢到不能用
因为默认 autocommit = ON，每条 INSERT 都是独立事务：每次都要写 redo log（innodb_flush_log_at_trx_commit = 1 时强制刷盘）、解析 SQL、校验外键/唯一索引、更新 B+ 树节点。实测吞吐常低于 300 行/秒，百万行要跑一个多小时。
更隐蔽的坑是：RAND()、NOW() 这类函数在循环内反复求值，无法预编译优化；SELECT ... FOR UPDATE 嵌套在循环里还会放大锁竞争。
这不是语法错，是设计反模式——存储过程能“做”，不代表该“这么写”。
START TRANSACTION + 分批提交才是可行底线
把 100 万行拆成 1000 行/批，日志刷盘次数从 100 万次降到约 1000 次，性能提升 10～100 倍。关键动作只有三步：
-
START TRANSACTION必须显式写在BEGIN后，不能依赖默认行为 - 用
IF i % 1000 = 0 THEN COMMIT; START TRANSACTION;控制节奏 - 循环结束后必须补一次
COMMIT，否则最后不足 1000 行的批次会丢失
示例片段：
START TRANSACTION; WHILE i <h3>比存储过程更优的替代方案有哪些</h3> <p>真要插百万级数据，优先考虑绕过 SQL 解析层的路径：</p>
- MySQL 用
LOAD DATA INFILE：跳过解析、权限检查、语句重写，快 5–10 倍 - 应用层用
executemany()（Python）或addBatch()（Java）：驱动自动拼多值INSERT，还能参数化防注入 - 先
INSERT INTO #staging SELECT卸到临时表，再分批INSERT INTO target SELECT ... FROM #staging LIMIT 1000 OFFSET ?：避免动态 SQL 作用域问题
注意：max_allowed_packet 默认 4MB，拼 1000 行 VALUES 很容易超限，得提前调大。
临时禁用约束和索引的适用边界
仅限离线初始化或 ETL 场景，线上实时写入绝对禁用：
- MySQL：
SET FOREIGN_KEY_CHECKS = 0+ALTER TABLE t DISABLE KEYS（针对 MyISAM）或ALTER TABLE t DROP INDEX（InnoDB 需手动删再建） - PostgreSQL：
SET CONSTRAINTS ALL DEFERRED或临时DROP INDEX，但主键/唯一索引不可删
恢复后必须验证数据一致性——禁用不是提速银弹，而是把校验成本从写入时挪到事后。
真正卡性能的地方，往往不在循环逻辑本身，而在 max_allowed_packet、innodb_log_file_size、临时表空间配置这些默认值上。没调参就写存储过程，等于在高速路上骑自行车还怪路不平。
