改了innodb_flush_log_at_trx_commit还没变快，是因为未关闭sync_binlog或存在非事务型写入，磁盘I/O瓶颈可能卡在binlog同步或fsync本身。
为什么改了 innodb_flush_log_at_trx_commit 还没变快？
这个参数控制事务提交时日志刷盘行为，但效果不明显往往是因为你没关掉 sync_binlog 或者用了非事务型写入（比如 INSERT ... SELECT、LOAD DATA）。InnoDB 日志刷盘只是链路一环，磁盘 I/O 瓶颈可能卡在 binlog 同步或 fsync 本身。
-
innodb_flush_log_at_trx_commit = 1：每次事务提交都调用fsync()到磁盘 —— 安全但慢，尤其在机械盘或高并发小事务场景 -
= 2：只写入 OS 缓存（write()），不fsync()—— 依赖 OS 周期性刷盘，崩溃可能丢 1 秒数据 -
= 0：每秒一次fsync()，事务提交只写内存 —— 性能最好，但崩溃最多丢 1 秒事务
innodb_flush_log_at_trx_commit = 2 在什么情况下会丢数据？
不是“只要设成 2 就一定丢”，而是取决于 MySQL 进程崩溃时机和 OS 行为。如果 MySQL 进程异常退出（比如 kill -9、OOM kill），而 OS 还没把 log buffer 写到磁盘，这部分事务就不可恢复。
- Linux 默认
vm.dirty_ratio是 30%，意味着脏页可能滞留较久；若系统负载高，OS 刷盘延迟可能超预期 - 容器环境更危险：宿主机重启或 cgroup 内存超限触发 OOM，MySQL 进程被杀，
=2下未刷盘日志直接蒸发 - 云盘（如 AWS gp3、阿里云 ESSD）的“持久化”不等于“立即落盘”，底层有缓存层，
=2仍存在窗口期
和 sync_binlog 配合时最容易踩的坑
主从一致性或崩溃恢复依赖 binlog 和 redo log 的逻辑顺序。如果两者刷盘策略不匹配，会导致备份不可用、GTID 跳变、甚至主从复制中断。
-
sync_binlog = 1+innodb_flush_log_at_trx_commit = 1：最安全，但双fsync开销叠加，TPS 明显下降 -
sync_binlog = 0+=2：性能好，但 binlog 可能比 redo 多/少几条事务，mysqldump --single-transaction备份后恢复可能主键冲突或漏数据 - 线上常见错误配置：
sync_binlog = 1000+=1—— binlog 批量刷盘导致主从延迟毛刺，且无法精确回档到某秒
怎么验证当前生效的刷盘行为？
别只看 SHOW VARIABLES，它只反映配置值。真正要看的是实际 I/O 模式和延迟分布。
- 查
SHOW ENGINE INNODB STATUS\G，关注Log sequence number和Log flushed up to差值 —— 持续拉大说明刷盘滞后 - 用
iostat -x 1观察await和%util，如果await > 10ms且%util ≈ 100%，说明磁盘已成瓶颈，调参数意义不大 - 开启
performance_schema，查events_waits_summary_global_by_event_name中wait/io/file/innodb/innodb_log_file的平均等待时间
innodb_flush_log_at_trx_commit = 2 在 SSD 上通常提升 3–5 倍 TPS，但前提是 binlog 不拖后腿、监控能及时发现刷盘延迟突增——这点常被忽略。 
