设为1最安全但性能最低（TPS 1000~3000），每次COMMIT都fsync；设为2折中，日志写入OS缓存、每秒刷盘，崩溃最多丢1秒事务，吞吐提升2–3倍；设为0风险最高，仅每秒刷盘一次，进程崩溃即丢失该秒全部事务，仅适用于日志类可丢数据场景。
innodb_flush_log_at_trx_commit 设为 0/2/1 的实际影响
这个参数直接决定事务提交时 redo log 是否落盘，是性能与安全最敏感的开关。设为 1（默认）时，每次 COMMIT 都触发 fsync，数据绝对不丢，但写入吞吐常被压到 1000~3000 TPS；设为 2 时，日志只写入 OS 缓存，每秒刷一次盘，崩溃时最多丢 1 秒事务，实测写入能力可提升 2–3 倍；设为 0 时，仅每秒刷一次 buffer 到磁盘，进程崩溃即丢失该秒所有事务，风险极高，仅适合日志类、可丢数据场景。
sync_binlog 必须和 innodb_flush_log_at_trx_commit 协同调整
单独调 innodb_flush_log_at_trx_commit 不足以保障主从一致性。如果启用了 binlog（如做主从或 GTID），sync_binlog 必须同步考虑：
-
sync_binlog=1+innodb_flush_log_at_trx_commit=1：双一标准，最安全，但性能最差 -
sync_binlog=1+innodb_flush_log_at_trx_commit=2：推荐组合，崩溃时 binlog 和 redo 可能不一致，但操作系统级 crash 概率低，多数业务可接受 -
sync_binlog=0：binlog 完全依赖文件系统缓存，主机断电即丢 binlog，主从断裂风险高，不建议生产使用
innodb_flush_method 决定数据页刷盘路径，不是可有可无的选项
这个参数控制 InnoDB 如何把脏页写到磁盘，直接影响 I/O 效率和 double-write 机制是否生效：
-
innodb_flush_method=O_DIRECT：绕过 OS 缓存，直接写设备，避免双重缓存，减少内存压力，SSD 环境下最稳妥 -
innodb_flush_method=FSYNC：先写 OS 缓存再 fsync，对 HDD 更友好，但可能引发 buffer pool 与文件系统缓存争用 -
innodb_flush_method=O_DSYNC：仅同步日志文件，数据文件不强制同步，极少用，容易导致恢复异常
注意：O_DIRECT 在某些旧版 ext3 或 NFS 上可能报错，需确认文件系统支持；若启用 innodb_doublewrite=ON（默认），O_DIRECT 是唯一推荐值。
脏页刷新节奏受 innodb_max_dirty_pages_pct 和自适应刷新共同约束
即使日志刷得快，脏页堆积太多也会在 checkpoint 时突然卡住。关键点在于：
-
innodb_max_dirty_pages_pct默认 75，表示脏页占比超该阈值才主动刷；设太低（如 30）会导致频繁刷盘，I/O 毛刺增多 -
innodb_adaptive_flushing=ON（默认）会让 MySQL 根据 redo log 生成速度动态调节刷脏页节奏，比固定阈值更平滑 - 若观察到
Innodb_buffer_pool_wait_free非零，说明 buffer pool 没空闲页可用，正在等脏页刷出，此时应检查innodb_io_capacity是否匹配磁盘真实吞吐（SSD 建议设 2000+）
真正容易被忽略的是：innodb_max_dirty_pages_pct 和 innodb_adaptive_flushing 是联动生效的，关掉自适应后，仅靠百分比阈值无法应对突发写入高峰。
