innodb_flush_log_at_trx_commit=0可提升批量插入吞吐量3–5倍，但极端情况下最多丢失1秒内已提交事务；需与sync_binlog协同、配合事务批次控制及应用层优化才能发挥实效。
innodb_flush_log_at_trx_commit=0 真的能提速，但得清楚丢什么
设成 0 后，InnoDB 不再每次事务提交都刷 redo log 到磁盘，而是每秒刷一次。实测在批量插入场景下，吞吐量可提升 3–5 倍。但它不是“无代价加速”：极端断电或 MySQL 崩溃时，最多丢失最近 1 秒内已提交但未刷盘的事务——这点必须和业务方对齐是否可接受。
- 值为
1（默认）：强一致性，每次 commit 都 fsync，最安全也最慢 - 值为
2：commit 时写入 OS 缓存，不强制 fsync；比0多一层缓冲，崩溃时仍可能丢数据，但概率略低 - 值为
0：完全交由后台线程每秒刷盘；性能最高，但风险最明确
别只改这一个参数就上线。它和 sync_binlog 要协同看：如果开了 binlog 且 sync_binlog=1，而 innodb_flush_log_at_trx_commit=0，主从一致性会出问题——因为 binlog 已落盘、redo 还在内存，crash 后备库可能多出一条记录。
为什么不能单独调这个参数就以为万事大吉
这个参数只影响 redo log 刷盘频率，但插入慢往往卡在别的环节：max_allowed_packet 太小导致批量 SQL 被截断、autocommit=1 让每条批量 INSERT 仍自成事务、客户端驱动没启用 batch 模式（如 PyMySQL 默认不合并 execute() 调用）——这些都会让 innodb_flush_log_at_trx_commit 的优化效果打折扣。
- 检查当前值：
SELECT @@innodb_flush_log_at_trx_commit; - 动态修改（重启不生效）：
SET GLOBAL innodb_flush_log_at_trx_commit = 0; - 必须同步改配置文件（
my.cnf），否则重启后还原 - 应用层代码里仍要显式用
BEGIN/COMMIT包裹多批插入，否则单批 INSERT 就是一次事务，0也没意义
配合事务批次大小才能真正稳住性能
innodb_flush_log_at_trx_commit=0 放宽了日志刷盘约束，但事务本身仍有开销：undo log 增长、锁持有时间、内存占用。一次性塞 10 万行进一个事务，容易触发 innodb_lock_wait_timeout 或撑爆 innodb_log_file_size。
- 推荐每事务控制在 1 万～5 万行（视单行大小而定）
- 若报错
Lock wait timeout exceeded，说明事务太久，得拆更小批次 - 若监控发现
Innodb_os_log_pending_fsyncs持续偏高，说明后台刷盘跟不上，需调大innodb_log_file_size - 禁用唯一索引、外键检查（
SET foreign_key_checks = 0）、关闭自动提交（SET autocommit = 0）这些动作，必须和该参数一起上
真正压测时你会发现：光调 innodb_flush_log_at_trx_commit 只能解决 30% 的瓶颈，剩下 70% 在 SQL 写法、网络交互、索引维护和事务粒度上——参数是杠杆，但支点得靠代码和流程来垫。
