innodb_flush_log_at_trx_commit=1因每次事务提交都强制fsync导致磁盘i/o瓶颈；设为2可提升吞吐但最多丢失1秒数据，设为0风险更高；需协同sync_binlog调整，并优化缓冲池命中率、sql及io配置。
innodb_flush_log_at_trx_commit=1 为什么直接压垮磁盘写入
默认值 innodb_flush_log_at_trx_commit = 1 意味着每次事务提交都必须执行一次 fsync()，把 redo log buffer 强制刷到磁盘。在高并发写入场景下（比如每秒上千事务），这等价于每秒触发上千次磁盘物理写，尤其对机械盘或未配掉电保护的 SSD，await 会飙升、%util 持续 100%，I/O 成为绝对瓶颈。
常见错误现象包括：
- 主库
Seconds_Behind_Master持续增长，但从库 IO Thread 没积压——说明是主库自己写不过来 -
SHOW ENGINE INNODB STATUS中Log sequence number增长缓慢，但Log flushed up to明显滞后 - iostat 显示
w/s不高，但await> 50ms，svctm却只有 1–2ms——典型 fsync 阻塞
设成 2 或 0 真的能用？风险在哪
innodb_flush_log_at_trx_commit = 2 把日志写入 OS page cache（不刷盘），由后台线程每秒 fsync 一次；= 0 则完全交由 OS 决定，连 write() 都不保证立即发出。两者都能让写吞吐翻倍以上，但崩溃时数据丢失窗口不同：
-
= 2：最多丢失最近 1 秒内已提交事务（MySQL 进程 crash 不丢，OS crash 或断电可能丢） -
= 0：可能丢失最近几秒甚至更多（取决于 OS 脏页回写策略），且无法与sync_binlog协同保障主从一致性 - 若同时开启
binlog和 GTID，= 0会导致 binlog 与 redo log 不一致，复制直接中断
生产环境只推荐 = 2，且必须搭配 sync_binlog = 1000 或 sync_binlog = 0（后者需接受 binlog 可能丢失）。
为什么不能只调这个参数就完事
单独改 innodb_flush_log_at_trx_commit 是治标不治本。如果缓冲池命中率长期低于 95%，大量 SELECT 还在读盘；如果慢查询没索引，UPDATE/DELETE 还在反复扫表——写压力降了，读 I/O 依然卡死磁盘。
- 必须同步检查
Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads，算出命中率 - 必须确认
tmp_table_size和sort_buffer_size足够大，避免排序/JOIN 溢出到磁盘临时表 - 若使用 SSD，务必设
innodb_flush_method = O_DIRECT，否则 OS cache + InnoDB buffer 双重缓存反而加剧内存争用和 swap
动态修改要注意的硬限制
MySQL 5.7+ 支持运行时调整，但有两条铁律：
- 该值只能在全局级别修改：
SET GLOBAL innodb_flush_log_at_trx_commit = 2，会话级设置无效 - 修改后新连接立即生效，但已有长事务仍按旧规则刷盘——所以要等活跃事务自然结束或主动 kill
- 某些云厂商 RDS（如阿里云）禁用该变量的动态修改，必须重启实例；而 Aurora 完全不支持修改，它用自研日志流替代 redo log 刷盘逻辑
最容易被忽略的是：这个参数和 sync_binlog 必须协同调整。只改前者不碰后者，binlog 仍每事务刷盘，I/O 压力只是从 redo log 搬到了 binlog 文件——问题照旧。
