WAL显著提升事务写入吞吐的核心在于将随机写转换为顺序写；InnoDB通过redo log循环文件实现顺序IO，结合组提交机制使多次事务共享一次fsync，再协同sync_binlog参数权衡一致性与吞吐，而checkpoint推进速率与日志空间匹配度才是长期吞吐的关键瓶颈。
WAL为什么能显著提升事务写入吞吐
核心就一条：把随机写变成顺序写。InnoDB更新数据时，实际要改的是磁盘上分散的.ibd文件里的某些16KB页，而这些页物理位置毫无规律——一次UPDATE可能触发三次磁盘寻道；但redo log是固定大小的循环文件（如ib_logfile0、ib_logfile1），所有日志都追加写入末尾，天然顺序IO。
innodb_flush_log_at_trx_commit=1时吞吐仍可观的原因
很多人以为innodb_flush_log_at_trx_commit=1（每次提交都fsync）必然卡吞吐，其实不然。关键在于InnoDB的组提交（Group Commit）机制：
- 多个并发事务的
redo log会先攒在redo log buffer中 - 当第一个事务调用
fsync时，InnoDB会把当前buffer里所有待刷的日志一并落盘 - 后续几个事务的提交只需等待这次统一刷盘完成，不各自发起IO
这意味着即使每秒有1000个事务提交，实际磁盘fsync次数可能只有几十次——吞吐瓶颈不在日志落盘本身，而在日志生成与缓冲区竞争。
sync_binlog和innodb_flush_log_at_trx_commit配合影响真实吞吐
单独调优innodb_flush_log_at_trx_commit不够，必须和sync_binlog协同看：
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
-
innodb_flush_log_at_trx_commit=1+sync_binlog=1：两阶段提交强一致，但两次fsync（redo + binlog）串行执行，延迟翻倍，吞吐受限 -
innodb_flush_log_at_trx_commit=1+sync_binlog=100：redo严格落盘，binlog批量刷，吞吐明显上升，但崩溃可能丢失最多99个事务的binlog -
innodb_flush_log_at_trx_commit=2+sync_binlog=1000：redo只写到OS cache（write），binlog也缓存，吞吐最高，但断电可能丢1秒内所有已提交事务
生产环境常见折中是innodb_flush_log_at_trx_commit=1配sync_binlog=100~1000，既保redo安全，又避免binlog拖慢整体提交链路。
容易被忽略的吞吐瓶颈：checkpoint age逼近上限
即使日志刷盘很快，吞吐也可能突然暴跌——典型现象是SHOW ENGINE INNODB STATUS里看到Log sequence number和Last checkpoint at差值持续接近innodb_log_file_size × N总容量。
这时InnoDB被迫同步刷脏页（sync flush），阻塞所有新写入，直到checkpoint追上来。这不是日志写慢，而是后台刷盘太慢或innodb_log_file_size设得太小导致日志空间反复紧张。
所以真正限制长期吞吐的，不只是单次fsync耗时，更是checkpoint推进速率与日志循环空间的匹配度。
