批量提交事务可显著提升MySQL性能，关键在于合理控制事务边界、避免频繁COMMIT、拆分大事务、使用INSERT...SELECT或LOAD DATA INFILE批量导入，并确保显式提交或回滚。
批量提交比单条提交快得多
MySQL 事务性能瓶颈常出现在频繁 COMMIT 上。每次 COMMIT 默认触发一次磁盘刷写（受 innodb_flush_log_at_trx_commit=1 控制），哪怕只改一行，也会有完整日志落盘开销。
实操建议：
- 把多条
INSERT/UPDATE合并在一个事务里提交，例如 100–1000 行一批，避免每行都COMMIT - 确认应用层没有隐式自动提交（如 JDBC 的
autoCommit=true或 Pythonconnection.autocommit = True） - 若业务允许短暂延迟一致性，可临时调低
innodb_flush_log_at_trx_commit到 2（日志仅写入 OS 缓存），但注意主机崩溃会丢最多 1 秒事务
关闭 autocommit 后务必显式控制 COMMIT/ROLLBACK
很多人以为关了 autocommit 就万事大吉，结果事务一直没提交，连接卡住、锁不释放、INFORMATION_SCHEMA.INNODB_TRX 里堆积长事务。
常见错误现象：
- 执行完
UPDATE后程序退出，没发COMMIT→ 事务挂起，行锁持续占用 - 异常路径遗漏
ROLLBACK→ 下次同连接执行 SQL 报错ERROR 1399 (XAE04): XAER_RMFAIL或死锁 - Python 中用
with conn但没 catch 异常做回滚，导致连接池复用时携带未结束事务
推荐做法：用 try/except 包裹事务块，finally 或 __exit__ 中确保 COMMIT 或 ROLLBACK；Go 中用 defer tx.Rollback() + 显式 tx.Commit() 覆盖成功路径。
大事务拆分：避免锁升级和 undo 日志膨胀
单个事务更新 50 万行，不仅慢，还可能触发 InnoDB 锁升级（行锁→表锁）、填满 undo log 表空间，甚至让从库复制延迟飙升。
判断是否属于“大事务”：
SELECT TRX_ID, TRX_ROWS_MODIFIED, TRX_STATE FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_ROWS_MODIFIED DESC LIMIT 5;- 若
TRX_ROWS_MODIFIED > 10000且TRX_STATE = 'RUNNING'，优先考虑拆分
拆分策略：
- 按主键或时间字段分段，例如
WHERE id BETWEEN ? AND ?，每次处理 5000 行 - 每次分段后
COMMIT，释放锁和 undo 空间 - 避免在拆分循环中重复全表扫描——加覆盖索引或用游标式查询（
SELECT ... WHERE id > last_id ORDER BY id LIMIT 5000）
insert into ... select 和 load data infile 更适合大批量导入
用循环拼 INSERT VALUES (...),(...),... 插入 10 万行，不如一条 INSERT INTO t SELECT ... FROM other_table 或 LOAD DATA INFILE 快，因为前者仍走逐行解析+事务日志路径，后者绕过部分 SQL 层开销，直接走存储引擎批量接口。
注意事项：
-
INSERT INTO ... SELECT默认在REPEATABLE READ隔离级别下会加临键锁（next-key lock），可能锁住范围；如只需数据迁移，可临时切到READ COMMITTED -
LOAD DATA INFILE要求文件在 MySQL 服务端磁盘，且需开启local_infile=ON（客户端和服务端都要设） - 两种方式都不受
max_allowed_packet限制（不像批量INSERT可能超限报错）
真正影响事务提交性能的，往往不是 SQL 写法本身，而是事务边界怎么划、锁什么时候放、日志何时刷。这些地方一松一紧，吞吐量可能差十倍。别只盯着索引和执行计划。
