innodb_flush_log_at_trx_commit=0写得快但不安全，因其每秒刷盘一次且事务提交时不刷盘，崩溃时最近一秒已提交事务全丢失，仅适用于可容忍数据丢失的场景。
innodb_flush_log_at_trx_commit=0 为什么写得快但不安全
这个配置直接控制事务日志（redo log）刷盘时机，0 表示每秒把日志缓冲区（log buffer）刷一次到磁盘，事务提交时完全不刷。所以大量小事务能攒批写入，吞吐飙升——但一旦 MySQL 崩溃或服务器断电，最近一秒内已提交的事务全丢。
- 适用场景仅限：压测、离线导入、日志类临时表，且业务能容忍数据丢失
- 不能用于金融、订单、账户等任何强一致性场景
- 和
sync_binlog配合时尤其危险：binlog 已落盘而 redo log 没刷，主从复制会因 crash 后恢复不一致导致 GTID 错乱或复制中断
innodb_flush_log_at_trx_commit=1 是默认值，但真的够用吗
设为 1 时，每次事务提交都调用 fsync() 把日志刷到磁盘，保证 ACID 中的 Durability。这是唯一能同时满足崩溃安全与主从一致的选项。
- 性能瓶颈常出现在高并发小事务（如秒杀扣库存），每笔都
fsync会卡在磁盘 I/O 上 - SSD 能缓解但不消除问题；NVMe 盘下延迟可压到 100μs 级，但吞吐仍受限于
fsync调用频次 - 如果应用层做了批量提交（比如 10 条 SQL 包在一个
BEGIN...COMMIT里），实际fsync次数大幅下降，比单条提交快得多
innodb_flush_log_at_trx_commit=2 的折中逻辑和隐藏风险
设为 2 表示事务提交时把日志写入操作系统缓存（write()），但不强制 fsync()；由后台线程每秒刷一次盘。它比 0 安全（OS crash 会丢最多 1 秒数据），比 1 快（避免每次 fsync）。
- 真正风险不在 MySQL 自身崩溃，而在 OS kernel panic 或突然断电——此时 OS 缓存里的日志还没落地
- 某些云厂商的“本地盘”实为网络存储挂载（如 AWS i3en 的 NVMe + EBS backend），
write()可能跨网络，延迟抖动大，2的实际安全性比预期低 - 监控时注意
Innodb_os_log_written和Innodb_log_waits：后者非零说明 log buffer 频繁写满，正在被迫阻塞等待刷盘，即使设了2也会影响响应
调整后必须验证的三个实际指标
改完 innodb_flush_log_at_trx_commit 不能只看 TPS 上升，要盯住底层行为是否符合预期。
- 用
strace -p $(pgrep mysqld) -e trace=fsync,write观察实际fsync调用频率，确认是否真按配置执行 - 查
SHOW ENGINE INNODB STATUS\G里的Log sequence number和Log flushed up to差值，持续 > 1MB 说明刷盘滞后严重 - 对比
uptime和mysqld进程启动时间，若机器刚重启就出现大量Innodb_log_waits，大概率是 log file size（innodb_log_file_size）太小，和本参数形成负向耦合
真正难调的是平衡点：既要扛住流量峰值，又不能把日志刷盘拖成单点瓶颈。很多时候问题不在这个参数本身，而在事务粒度是否合理、批量逻辑是否缺失、或者磁盘队列深度是否被其他进程挤占。
