wal机制本质是“日志先于数据落盘”，由innodb_flush_log_at_trx_commit参数强制控制：=1时每次commit均fsync确保日志落盘，满足强持久性；=2和=0下commit成功不保证日志已落盘，崩溃可能丢失最多1秒事务。
WAL机制的本质就是“日志先于数据落盘”
在MySQL 5.7中，WAL（Write-Ahead Logging）不是抽象概念，而是由innodb_flush_log_at_trx_commit参数直接控制的硬性行为。只要事务提交（COMMIT），InnoDB就必须确保对应的redo log已写入磁盘——否则崩溃后无法重放，就违反了ACID中的Durability。这不是可选优化，是InnoDB引擎强制执行的规则。
容易误以为“只要SQL执行成功，数据就安全了”，其实不然：数据页（.ibd文件）可能还卡在Buffer Pool里没刷盘，真正扛住崩溃的是那几KB的redo log记录。比如一条UPDATE t SET name='alice' WHERE id=1，redo log只记“表空间2、页号105、偏移量2048处写入6字节'alice'”，而整个16KB的数据页根本没动。
看懂innodb_flush_log_at_trx_commit的三个取值差异
这个参数决定了“日志先于数据”的严格程度，直接影响持久性和性能平衡：
-
=1（默认）：每次COMMIT都调用fsync()，强制OS把log buffer刷到磁盘。强持久性，但每秒事务数（TPS）受限于磁盘fsync延迟。 -
=2：COMMIT时仅写入OS page cache，不fsync()；后台线程每秒调用一次fsync()。断电可能丢失最多1秒内已提交的事务日志（注意：不是数据页，是日志本身未落盘）。 -
=0：log buffer由后台线程每秒刷一次，COMMIT完全不触发刷盘。崩溃可能丢失上一秒所有已提交事务——因为日志根本没机会写磁盘。
关键点：=2和=0下，即使COMMIT返回成功，也不能保证日志已落盘；只有=1才能满足“提交即持久”。很多线上故障源于误配为0却期望强一致性。
如何验证Redo Log是否真在事务提交时落盘
不能只看SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit'，得观察实际行为：
- 用
strace -e trace=fsync,write -p $(pidof mysqld)抓mysqld进程的系统调用，执行INSERT; COMMIT;后看是否立刻出现fsync()（=1时必现，=2时大概率不出现）。 - 查
SHOW ENGINE INNODB STATUS\G里的Log sequence number和Log flushed up to字段差值。若差值长期为0，说明log buffer刷盘及时；若持续增长且不回落，可能是刷盘线程被阻塞或=0/2配置下积压。 - 模拟断电前手动执行
FLUSH LOGS，再杀掉mysqld进程重启，检查数据是否完整——这是最直白的WAL有效性验证。
注意：FLUSH LOGS会触发redo log file切换，但不会强制刷log buffer；它只保证当前日志文件关闭，新日志写入新文件，不替代fsync()。
Redo Log循环写满时的隐式刷脏页行为
MySQL 5.7中redo log是固定大小（由innodb_log_file_size × innodb_log_files_in_group决定），循环覆盖。当写指针追上读指针（即log满），InnoDB必须腾出空间——它不会等后台线程，而是主动触发脏页刷盘，直到释放足够redo空间。
这种场景下，你会看到：
- 大量
Page cleaner线程活动，Innodb_buffer_pool_pages_dirty陡降； - 磁盘IO飙升，
innodb_data_fsyncs计数猛增； - 事务响应变慢，因为写log buffer时发现空间不足，要先等脏页刷出。
这意味着：即使innodb_flush_log_at_trx_commit=1，log写满也会迫使数据页提前落盘——WAL不是隔离的，它和buffer pool刷脏逻辑深度耦合。调大redo log总容量（如从默认48MB×2升到128MB×2）能显著减少这类干扰。
真正难调试的不是“日志怎么写”，而是“日志写满后系统如何自救”。很多性能抖动源于redo log太小，导致频繁触发强制刷脏，掩盖了本应异步完成的IO压力。
