MySQL redo log 性能受大小、刷盘策略及I/O环境动态影响：过大延长恢复时间并引发I/O突刺，过小导致频繁checkpoint；innodb_flush_log_at_trx_commit=1最安全但性能低，=2或0提升吞吐但有数据丢失风险；与binlog共存时需协同优化存储路径与文件系统。
MySQL 的 redo log 对性能影响显著，但不是单向的“越大越好”或“越小越快”，而是在数据安全、I/O 压力与吞吐能力之间动态权衡的结果。
redo log 大小直接影响写入吞吐与刷盘频率
redo log 文件（由 innodb_log_file_size 控制单个文件大小）决定了日志缓冲区循环写入的空间余量。空间过小会导致频繁 checkpoint 和脏页强制刷盘，引发 I/O 尖峰；过大则延长恢复时间，且可能因日志归档/切换延迟带来短时阻塞。
- 实测显示：在 MySQL 5.7.26、10 表共 12GB 数据场景下，innodb_log_file_size 从 50MB 增至 500MB，QPS 提升约 2.6 倍（2297 → 6078）；但继续增至 1024MB 后，出现明显抖动，部分时段 QPS 下滑超 30%
- 根本原因在于：过大的日志文件会拉长 checkpoint 周期，导致 flush list 积压大量低 LSN 脏页，最终触发批量刷盘，形成 I/O 突刺
刷盘策略决定事务响应延迟与数据安全性
redo log 是否立即落盘，由 innodb_flush_log_at_trx_commit 参数控制，它直接绑定每笔事务的提交耗时：
- 值为 1（默认）：每次 commit 都触发 fsync 到磁盘 → 最安全，但高并发下易成瓶颈，尤其机械盘或未优化的 SSD
- 值为 2：log 写入 OS buffer 后即返回 → 性能提升明显，断电可能丢失 1 秒内事务（因 OS buffer 未刷盘）
- 值为 0：每秒批量刷一次 → 吞吐最高，但崩溃可能丢失最多 1 秒事务，适用于日志类、可重算场景
顺序写优势被随机 I/O 拖累时，性能反而下降
redo log 本质是顺序追加写，本应高效。但若部署不当，会退化为随机 I/O：
- redo log 文件与数据文件混放在同一物理磁盘（尤其 HDD），刷日志和刷脏页相互干扰
- 文件系统未启用 barrier 或挂载选项（如 noatime, data=ordered）导致额外元数据开销
- SSD 寿命管理策略（如过度 GC）掩盖了顺序写优势，需结合 fio 测试真实 write latency
与其他日志协同工作会放大 I/O 压力
redo log 不是孤立存在。当开启 binlog（如主从复制或 GTID 场景），MySQL 默认采用两阶段提交（2PC），要求 redo log 与 binlog 均持久化后才确认事务成功：
- 此时 sync_binlog=1 + innodb_flush_log_at_trx_commit=1 组合会触发两次独立 fsync，I/O 成倍增加
- 若 binlog 和 redo log 存于不同磁盘，还涉及跨设备调度延迟；建议将二者置于同一高速 NVMe 卷，并用 XFS 文件系统减少锁竞争
