MySQL事务提交性能优化需平衡吞吐量与持久性：通过调整innodb_flush_log_at_trx_commit（1/0/2）、批量提交、关闭autocommit、配合binlog组提交实现。
MySQL 事务提交频率直接影响写入性能和数据一致性，关键在于平衡吞吐量与持久性要求。默认情况下，每执行一次 COMMIT 就触发一次磁盘刷写（受 innodb_flush_log_at_trx_commit 控制），频繁提交会放大 I/O 开销；而批量提交虽提升性能，但可能增加崩溃时的数据丢失风险。
调整 innodb_flush_log_at_trx_commit 参数
该参数决定 InnoDB 日志刷新策略，是控制提交开销的核心：
- 值为 1（默认）：每次事务提交都把日志写入并刷到磁盘，最安全，但性能最低；适合金融、账务等强一致性场景。
- 值为 0：日志每秒写入并刷盘一次，事务提交仅写入内存缓冲区；崩溃最多丢失 1 秒数据；适合日志类、埋点类高吞吐低一致性要求业务。
- 值为 2：每次提交写入操作系统缓存，但不强制刷盘，由 OS 每秒刷一次；崩溃可能丢失未刷盘的日志，但比 0 更可靠；多数 Web 应用的折中选择。
修改方式：SET GLOBAL innodb_flush_log_at_trx_commit = 2;（需 SUPER 权限，重启失效）或在 my.cnf 中配置后重启。
合理使用显式事务批量提交
避免“一条 SQL 一提交”，尤其在大批量插入/更新时：
- 将多条 DML 包裹在
BEGIN; ... COMMIT;中，减少日志刷盘次数；例如插入 1 万行，分 100 条一批提交，比逐条提交快数倍。 - 注意事务大小上限：过长事务会占用大量 undo log、锁资源，甚至触发
innodb_lock_wait_timeout或 OOM；建议单事务控制在 1–5 万行以内，具体视行宽和系统负载而定。 - 应用层可结合 JDBC 的
addBatch()/executeBatch()或 ORM 的批量操作接口实现。
启用 autocommit 并按需关闭
MySQL 默认开启 autocommit=1，即每条语句自动提交 —— 这对简单查询友好，但对批量写入是性能瓶颈：
- 批量操作前执行
SET autocommit = 0;，显式管理事务边界；操作完成再COMMIT;。 - 避免长期保持
autocommit=0不提交，否则连接会持续持有锁、阻塞其他事务，还可能被超时中断（wait_timeout）。 - 应用中应确保异常时调用
ROLLBACK，防止连接处于未结束事务状态。
配合 binlog 组提交（Group Commit）优化
当启用 binlog（如主从复制环境），InnoDB 和 binlog 的两阶段提交（2PC）可能成为瓶颈。开启组提交能显著缓解：
- 确保
sync_binlog = 1（保证 binlog 持久性）的同时，设置binlog_group_commit_sync_delay = 100000（单位微秒，即 0.1ms 延迟）和binlog_group_commit_sync_no_delay_count = 10（凑够 10 个事务再刷）可提升并发提交吞吐。 - 该机制依赖 MySQL 5.7+，且需
binlog_format = ROW效果更稳定。
事务提交不是越快越好，也不是越多越好。根据业务容忍度选对日志刷盘策略，用好批量和显式事务，再配合 binlog 协同优化，就能在性能与可靠性之间找到合适支点。
