事务提交慢主因是autocommit被意外关闭，需检查并设为1；批量插入应使用多值INSERT而非循环单条；调优innodb_flush_log_at_trx_commit=2（配sync_binlog=1）；大事务须分批处理并避免事务内非DB操作。
事务提交太慢，先看 autocommit 是否被意外关闭
MySQL 默认是开启 autocommit=1 的，但很多 ORM（比如 Django、SQLAlchemy）或连接池会显式设为 autocommit=0，导致每条 DML 都卡在事务里，直到你手动 COMMIT。这不是“慢”，是根本没提交——IO 压力全堆在最后一下。
实操建议：
- 连上数据库后立刻查
SELECT @@autocommit;，确认值为1 - 若用 Python + PyMySQL/MySQLdb，检查是否调用了
conn.autocommit(False)或conn.begin() - Spring Boot 项目重点看
spring.datasource.hikari.auto-commit配置，默认 true，但有人会误配成 false
批量插入时用 insert … values(),(),() 而不是循环单条 insert
单条 INSERT 在事务内执行，即使 autocommit=1，也会触发一次 redo log 写入 + 一次 binlog 写入（如果开启）。1000 行循环插入 ≈ 1000 次磁盘同步开销；而一条多值 INSERT 只算一次事务，redo 和 binlog 合并刷盘，吞吐能差 5–10 倍。
注意点：
-
max_allowed_packet限制了单条语句最大长度，超限会报错Packets larger than max_allowed_packet are not allowed - 值太多（比如上万）反而引发锁升级或内存压力，建议每批 500–2000 行，视行宽调整
- MyISAM 不支持事务，但依然受此优化影响——它靠表锁，批量写入减少锁竞争
innodb_flush_log_at_trx_commit=2 是吞吐与安全的折中点
这个参数直接控制事务提交时 redo log 的刷盘行为：1（每次 commit 都 fsync 到磁盘，最安全）、0（每秒刷一次，崩溃可能丢一秒数据）、2（写入 OS cache 就返回，由 OS 异步刷盘）。线上多数业务选 2，既避免 1 的频繁 IO，又比 0 更可靠。
但要注意：
- 必须搭配
sync_binlog=1使用才能保证主从一致性；否则 binlog 写了、redo 没刷，crash 后恢复可能主从不一致 - 云厂商 RDS（如阿里云 PolarDB、腾讯云 CynosDB）可能禁用该参数或强制为
1，改之前先确认平台限制 - SSD 性能好不代表可以盲目设为
1：高并发小事务下，fsync()仍是瓶颈，尤其容器环境 IO 共享更明显
大事务拆分：别让一个 UPDATE 跑 30 秒
长事务会拖住 undo log 不释放、阻塞 purge 线程、膨胀 ibdata 文件，还可能因锁等待触发 Lock wait timeout exceeded。优化不是“加索引”或“调 buffer pool”，而是从源头控制事务粒度。
怎么做：
- 用
WHERE id BETWEEN ? AND ?分页更新，每次 1000–5000 行，配合ORDER BY id避免扫描重复 - 避免在事务里做 HTTP 请求、文件读写、复杂计算——这些耗时和数据库无关，却把锁占着
- 监控
INFORMATION_SCHEMA.INNODB_TRX表，重点关注TRX_STARTED和TRX_ROWS_MODIFIED，及时发现“静默大事务”
真正难的不是知道要拆，而是业务逻辑里那些隐式事务：比如一个 HTTP 接口里开了事务，中间调了三次 DAO 方法，其中第二次失败回滚——没人意识到第一次的修改已锁表 2 秒。这种地方得靠代码层埋点或 AOP 日志抓，配置和 SQL 都救不了。
