批量插入为何如此之慢

“批量插入很慢”通常不是 SQL 本身的问题，而是写入路径上的某一环被放大了。下面按最常见原因给你一个排查清单，你可以对照看是哪一类。

一、最常见的慢点（90% 情况）

1️⃣ 一条一条提交事务（最致命）

INSERT INTO t VALUES (...);
INSERT INTO t VALUES (...);
...
COMMIT; -- 最后才提交

或每条都：

INSERT ...; COMMIT;

✅ 正确做法：

• 一次事务包住整批

BEGIN;
INSERT ...;
INSERT ...;
COMMIT;

2️⃣ 没用真正的“批量”

很多人以为这是批量：

for row in rows:
    insert(row)

✅ 真正批量：

• 多值 INSERT

INSERT INTO t (a,b,c) VALUES
 (1,2,3),
 (4,5,6),
 (7,8,9);

• 或 COPY / LOAD DATA / bulk insert

3️⃣ 索引太多

每插入一行：

• 主键
• 二级索引
• 唯一索引
  都要更新

✅ 优化：

• 插入前 临时禁用索引
• 插完再重建

ALTER TABLE t DISABLE KEYS;
-- insert
ALTER TABLE t ENABLE KEYS;

4️⃣ 外键检查

每一行都做父表校验

✅ 优化：

SET FOREIGN_KEY_CHECKS = 0;
-- insert
SET FOREIGN_KEY_CHECKS = 1;

二、数据库层面的隐藏成本

5️⃣ 日志 / WAL 写放大

• MySQL：binlog + redo
• PostgreSQL：WAL

批量大时：

• 磁盘 IO 成瓶颈

✅ 优化：

• 调大 innodb_buffer_pool_size
• 使用 SSD
• 减少 sync_binlog=1

6️⃣ 锁竞争

• 行锁 / 表锁
• 并发写入同一表

✅ 优化：

• 分批（如 1k~5k/批）
• 避免热点行

三、应用层问题

7️⃣ ORM 自动行为

很多 ORM 会：

• 自动 SELECT 主键
• 触发 trigger
• lazy flush

✅ 优化：

• 用原生批量 API
• 关闭审计 / 事件监听

8️⃣ 网络往返

每条 INSERT 一次 RTT

✅ 优化：

• 用 prepared statement
• 批量发送

四、什么时候“慢是正常的”

以下情况慢是正常的：

• 单批 > 50w 行
• 表有 10+ 索引
• 磁盘本身慢
• 主从同步

五、一句话总结

批量插入慢，90% 是因为：不是真批量 + 事务太碎 + 索引太多

如果你愿意，可以告诉我：

• 用的什么数据库（MySQL / PG / Oracle）
• 数据量 & 表结构
• 插入方式（代码 or SQL）

我可以直接给你针对性优化方案。