MySQL通过Redo日志刷盘策略（innodb_flush_log_at_trx_commit=0/1/2）控制持久性与性能平衡，结合Group Commit机制将多个事务的fsync批量执行，显著降低IO开销；开启binlog时，通过二阶段提交与Binlog Group Commit保障一致性并进一步优化IO效率。
MySQL 的 Redo 日志刷盘策略和 Group Commit 是保障事务持久性与提升并发性能的一体两面：前者决定“什么时候写磁盘”，后者解决“怎么更高效地写磁盘”。核心逻辑很直接——单个事务刷一次盘太慢，多个事务凑一起刷，摊薄 IO 成本。
Redo 日志的三种刷盘策略
关键参数是 innodb_flush_log_at_trx_commit，它控制事务提交时 redo log 的落盘行为：
-
值为 1（默认且最安全）：每次事务 COMMIT 时，立即将 redo log 从 buffer 写入 OS cache，并调用
fsync()强制刷到磁盘文件（ib_logfile*）。满足 ACID 中的 Durability，但每笔事务都触发一次磁盘 IO，高并发下易成瓶颈。 - 值为 0：事务提交时不写盘，完全交由后台线程每秒批量刷一次。性能最高，但崩溃可能丢失最多 1 秒内已提交事务的日志，不推荐生产环境使用。
- 值为 2：事务提交时只写入 OS cache（即 page cache），不立即 fsync；同样依赖后台线程每秒刷盘。兼顾一定安全性与性能，但若操作系统崩溃（而非 MySQL 崩溃），仍可能丢失日志。
Group Commit 如何缓解刷盘压力
即使设置为 innodb_flush_log_at_trx_commit = 1，MySQL 也不会让每个事务独自排队等磁盘。它通过 Group Commit 将多个事务的 redo log 刷盘动作“打包”执行：
- 事务进入 commit 流程后，先尝试获取全局 log sys mutex，但实际并不长期持有；而是快速登记自己要刷的 LSN 范围，加入等待队列。
- InnoDB 内部按阶段组织（Flush → Sync → Commit），每个阶段有一个独立队列和一把轻量锁；第一个到达的事务成为 leader，负责协调整个队列中所有事务的该阶段操作。
- 比如在 Sync 阶段，leader 会收集队列中所有事务的 redo log 起止 LSN，一次性调用
fsync()，完成后再统一唤醒其余事务。这样 10 个事务原本需 10 次 fsync，现在只需 1 次。 - LSN（Log Sequence Number）是单调递增的字节偏移量，确保组内事务日志顺序严格一致，恢复时可精准重放。
Redo 与 Binlog 的协同：二阶段提交 + 双组提交
当开启 binlog（如主从复制场景），MySQL 必须保证 redo 和 binlog 一致性，否则 crash 后可能造成主从数据不一致。为此采用：
- 二阶段提交（2PC）：prepare 阶段写 redo 并标记为 prepare 状态；commit 阶段写 binlog，成功后再将 redo 标记为 commit。binlog 作为协调者，决定最终是否提交。
- Binlog Group Commit：同样分 Flush/Sync/Commit 三阶段，各阶段也设队列与 leader。这样 binlog 写入也能批量刷盘，避免成为新瓶颈。
- 只有当 binlog 写入成功且 sync 完成，InnoDB 才允许 redo 进入最终 commit 状态。整个过程天然支持组提交嵌套，最大化磁盘 IO 效率。
实际效果与调优提示
Group Commit 不是开关型功能，而是在 innodb_flush_log_at_trx_commit = 1 下自动生效的底层机制。它的收益取决于并发事务密度：
- 低并发（如 QPS
- 高并发 OLTP 场景（如 QPS > 1000）：TPS 可提升 3–5 倍，延迟波动显著降低。
- 注意配合
innodb_log_buffer_size（默认 16MB）和innodb_log_file_size，避免频繁触发 buffer 满而提前刷盘，干扰 Group Commit 的聚合效果。
