直接结论：innodb_flush_log_at_trx_commit从1改为2是提升iops最有效且风险可控的操作；它使每事务fsync降为每秒一次，io大幅下降而tps反升，仅os崩溃时可能丢失最多1秒日志，需配合sync_binlog≥100、连接重连及日志文件调大验证。
直接结论：别盲目调高刷盘频率，而是根据业务容忍度降低它——innodb_flush_log_at_trx_commit 从默认的 1 改为 2，是提升 IOPS 最有效、风险可控的操作。
为什么改 innodb_flush_log_at_trx_commit 能显著降 IO？
这个参数决定事务提交时 redo log 是否立即落盘。值为 1（默认）时，每个事务都触发一次 fdatasync()，在高并发小事务场景下，IO 请求会打满磁盘队列；值为 2 时，只 write() 到 OS page cache，由后台线程每秒统一 fsync()，IO 合并效果明显。
实测数据：某写密集型日志服务将该值从 1 改为 2 后，磁盘写入带宽从 200 MB/s 降至约 10 MB/s，IOPS 下降超 10 倍，TPS 反而从 2400 升至 4100。
- 注意：
innodb_flush_log_at_trx_commit=2不等于“丢数据”，MySQL 进程崩溃不丢，仅 OS 级崩溃（如内核 panic）才可能丢失最多 1 秒日志 - 它和
sync_binlog是解耦的：若 binlog 开启，建议sync_binlog≥ 100，避免双“1”配置造成两轮 fsync 堆叠 - 不要设为 0：虽然性能最高，但 MySQL 意外终止（非 graceful shutdown）时，整个 log buffer（默认 16MB）内容全丢，不可控
改完之后必须验证的三件事
这个参数生效后，不能只看 TPS 上升就认为 OK，需确认底层行为是否符合预期：
- 查监控项：
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_fsyncs'，值应从“每事务一次”变为“约每秒一次”（允许小幅波动） - 确认应用连接已重连：用
SET GLOBAL innodb_flush_log_at_trx_commit = 2是即时生效的，但**只对新建立的连接有效**；老连接仍按旧值执行，需滚动重启或等待连接池自然更新 - 检查
innodb_log_file_size是否匹配：若日志文件太小（如默认 48MB），即使刷盘变少，checkpoint 仍频繁触发脏页刷新，IO 压力会转移——建议调大到 512MB，并配合停库重建
哪些场景绝对不能改？
不是所有系统都能接受 innodb_flush_log_at_trx_commit=2，关键看事务语义是否允许秒级丢失：
- 金融交易、支付订单、库存扣减类系统：必须保持 1，别碰
- 主库开启 GTID 且从库延迟敏感：若
innodb_flush_log_at_trx_commit=2+sync_binlog=0，binlog 和 redo log 落盘不同步，可能导致主从数据不一致或复制中断 - 使用 RAID 卡但未启用掉电保护（BBU/Flash Backup）：OS cache 写入后断电，日志仍可能丢失，此时设为 2 的安全性不如预期
真正影响效果的，从来不是参数本身，而是你是否清楚“这一秒日志丢了，业务会怎样”。很多团队把 innodb_flush_log_at_trx_commit 当成性能开关乱调，却没盯住 Innodb_os_log_written 增速和实际恢复窗口——这才是线上调参最该盯住的两个数字。
