设为2能提升写入速度，因事务提交时仅写入OS缓存、每秒fsync一次，减少I/O等待，吞吐常提升3~10倍；但MySQL崩溃或断电仍可能丢失最多1秒事务，需配合innodb_log_file_size等参数协同优化。
设为 2 是最常用且有效的折中方案，但直接改这个参数不解决根本问题——它只是把“刷盘压力”从每次提交转移到了每秒一次，前提是你的 redo log 写入节奏和脏页刷盘能力能跟上。
为什么 innodb_flush_log_at_trx_commit=2 能提写入速度
默认值是 1，表示每次 COMMIT 都强制把 redo log 从内存刷到磁盘（fsync），这是最安全但最慢的方式。设为 2 后，COMMIT 只写进操作系统的 page cache，由系统每秒调用一次 fsync 刷盘。这省掉了大量磁盘 I/O 等待，吞吐常提升 3~10 倍。
但要注意：这不是“无损加速”。若 MySQL 进程崩溃，最多丢失 1 秒内已提交但未刷盘的事务；若整个服务器断电，且 OS cache 未落盘，则同样可能丢失。
- 只影响事务持久性保障级别，不影响原子性、一致性、隔离性
- 必须配合
sync_binlog使用：设为 0（不强制 binlog fsync）可进一步提速，但主从一致性风险上升 - 在 SSD 上效果明显；在 HDD 或某些云盘（如部分 EBS gp3 未开启
disk_io_priority）上提升有限
设为 2 后反而变慢？先检查这几个点
常见错误现象：改完 innodb_flush_log_at_trx_commit=2，TPS 没涨，反而出现 innodb_row_lock_time 上升、Threads_running 波动剧烈、提交延迟飙升。
根本原因不是参数本身错了，而是底层日志和刷盘链路卡住了：
-
innodb_log_file_size太小 → checkpoint 频繁触发，导致批量刷脏页阻塞新写入 -
innodb_log_buffer_size不足 → 大事务（如单批插入 >1MB）反复 flush buffer，抵消了设为 2 的收益 -
innodb_io_capacity和innodb_io_capacity_max未按 SSD 实际 IOPS 设置 → 刷盘线程跟不上生成速度 - Buffer Pool 实例数不够（
innodb_buffer_pool_instancesinnodb_buffer_pool_size > 8GB 时）→ flush list 锁争用严重
搭配哪些参数才算真正生效
单独调 innodb_flush_log_at_trx_commit 是“半截优化”。要让它稳定起效，必须同步校准以下三项：
-
innodb_log_file_size：目标 checkpoint 间隔 ≥60 秒。用SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written'每 30 秒采样，算出平均每秒写入量（B/s），再乘以 60 × 2 得推荐值。MySQL 8.0+ 必须设innodb_log_files_in_group=2，改完需停机删旧ib_logfile*并重启 -
innodb_log_buffer_size：对单事务写入量大的场景（如 batch 插入 5000 行 JSON），建议设为 8~32MB。注意它只缓存 redo 日志，不缓存数据页 -
innodb_io_capacity：SSD 建议 2000~5000；NVMe 盘可设 8000+。该值直接影响后台刷脏页线程的调度频率
什么时候不该设为 2
不是所有业务都能接受 1 秒数据丢失风险。以下场景应坚持用 1：
- 金融类核心账务表（如用户余额、交易流水）
- 有强依赖 binlog 解析做实时风控或审计的系统
- 主库关闭
sync_binlog且从库启用了relay_log_recovery=ON的复制架构（易导致主从数据不一致） - 应用层没做幂等或重试补偿，且写入失败后无法回滚重试
真正难的不是选 1 还是 2，而是确认你是否清楚每一笔写入背后的数据语义、恢复边界和上下游依赖。参数只是杠杆，支点永远在业务逻辑里。
