关键词：批量插入；批量更新；LOAD DATA；事务优化；性能调优
大家好，我是小耶。批量操作是最容易被忽视的性能瓶颈。小数据量时什么都快，等数据量涨到几万行，循环单条INSERT能让用户等到崩溃。今天不讲复杂理论，直接给三个能落地的提速方法。
1 问题背景：为什么单条循环那么慢？
每次执行一条INSERT或UPDATE，数据库都要经历：SQL解析、权限检查、开启事务、加锁、写undo log、写redo log（事务提交时）、返回结果。这些固定开销在循环中重复了1万次。就像你每次只搬一块砖，来回跑1万趟，当然累。
另外，单条操作默认每执行一次就自动提交一次事务，频繁写磁盘，IO压力极大。
2 三种优化方案
2.1 方案一：一条INSERT插入多行
将多条VALUES合并成一条SQL：
sql
-- 慢：1万次插入，约30秒
INSERT INTO logs (msg) VALUES ('a');
INSERT INTO logs (msg) VALUES ('b');
...
-- 快：一次插入多行，约1秒（1万行）
INSERT INTO logs (msg) VALUES ('a'), ('b'), ... （所有行）;
注意：单条SQL大小受max_allowed_packet限制（默认4MB）。如果1万行超过限制，可以分批次，例如每1000行执行一次。
实测：1万行数据，逐条INSERT：28秒；多行INSERT（1000行/批）：1.2秒。
2.2 方案二：LOAD DATA文件导入（最快）
如果数据来源于CSV或TSV文件，LOAD DATA是最佳选择：
sql
LOAD DATA LOCAL INFILE '/tmp/data.csv' INTO TABLE logs
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
(msg);
优点：直接解析文件，跳过SQL层解析，比INSERT快5-10倍。 实测：1万行CSV导入，耗时约0.3秒。
注意事项：
- 需要文件读取权限，云数据库环境可能受限。
- 如果是超大文件（百万行），可以启用
DISABLE KEYS暂时关闭索引，导入后再重建。
2.3 方案三：批量UPDATE用临时表
逐条UPDATE同样慢。优雅的做法是创建临时表，一次性JOIN更新：
sql
-- 1. 建临时表
CREATE TEMPORARY TABLE tmp_updates (id INT, status VARCHAR(10));
-- 2. 批量插入要更新的数据
INSERT INTO tmp_updates VALUES (1,'done'), (2,'done'), ...;
-- 3. 一次性关联更新
UPDATE logs JOIN tmp_updates ON logs.id = tmp_updates.id
SET logs.status = tmp_updates.status;
优点：只产生一次事务，利用索引快速匹配，避免逐条更新。 实测：1万条更新，逐条UPDATE：32秒；临时表JOIN方式：0.8秒。
3 性能对比总表
| 操作类型 | 单条循环 | 批量方案 | 提升倍数 |
|---|---|---|---|
| 1万行INSERT | 28秒 | 1.2秒（1000行/批） | 23x |
| 1万行INSERT（文件） | 28秒 | 0.3秒（LOAD DATA） | 93x |
| 1万行UPDATE | 32秒 | 0.8秒（临时表JOIN） | 40x |
4 额外优化建议
- 调整事务提交频率：如果是批量插入且不需要严格一致性，可以临时设置
SET autocommit=0，手动每N行提交一次。 - 关闭索引检查：对于大批量导入（百万级），可先
ALTER TABLE t DISABLE KEYS，导入后ENABLE KEYS。 - **调高
innodb_flush_log_at_trx_commit**：批量操作时设置为2，可减少日志刷盘次数（接受短暂丢数据风险）。 - 使用专用导入工具：如MySQL的
mysqlimport、Percona的pt-archiver。
5 总结与建议
批量操作的核心思想是：减少事务数、减少网络往返、利用索引批量匹配。对于1万行以内的数据，多行INSERT或临时表JOIN已经足够；对于百万行级导入，建议使用LOAD DATA并配合关闭索引/调整日志参数。
建议开发规范中明确：禁止在生产环境循环单条执行DML，所有批量操作必须走批量接口。
小耶在手，SQL 不愁。
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
