innodb_log_file_size 配置与 Redo Log 优化

什么是 InnoDB Redo Log

Redo Log（重做日志）是 InnoDB 实现 ACID 事务特性的关键组件，用于崩溃恢复。它记录了对数据页的所有修改操作，确保已提交的事务不会丢失。

核心流程：

事务提交 → 写入 Redo Log（保证持久性）
         → 异步刷脏页到数据文件
崩溃恢复 → 读取 Redo Log → 重放未写入数据文件的修改

Redo Log 是物理日志，记录的是”在哪个页的哪个位置改了什么值”，格式非常紧凑，比数据文件小得多，所以写入速度极快。

Redo Log 的组成

Redo Log 由两个参数控制：
– innodb_log_file_size：每个 Redo Log 文件的大小
– innodb_log_files_in_group：Redo Log 文件的数量（默认 2）

总 Redo Log 空间 = innodb_log_file_size × innodb_log_files_in_group

┌────────────┐     ┌────────────┐
│ logfile 0  │ ←── │ logfile 1  │  → 循环写入
└────────────┘     └────────────┘
     ↑                    │
     └─────── 环形覆盖 ───┘

Redo Log 采用环形写入（circular buffer）方式：写满所有文件后，从第一个文件从头覆盖。关键是：被覆盖的空间必须是已经刷到数据文件的（即该日志对应的脏页已落盘）。

innodb_log_file_size 的影响

设置太小

1. 频繁检查点（Checkpoint）：Log 写满后必须强制刷脏页，产生 IO 尖刺
2. 脏页不能及时刷：导致 Checkpoint 操作变慢
3. 性能抖动：高峰期，写入速度 > 刷脏速度，日志快速写满，数据库被迫降速

症状：
– SHOW ENGINE INNODB STATUS 看到 Log sequence number 与 Last checkpoint at 差距很大
– 磁盘 IO 利用率周期性打满
– 高并发写入场景下吞吐量上不去

设置太大

1. 崩溃恢复时间长：MySQL 异常关闭后恢复时，需要回放所有未 checkpoint 的日志
2. 占用磁盘空间：Redo Log 文件本身占用空间

理论恢复时间：
– 恢复时间 ≈ (未 checkpoint 的日志大小) / (重放速度)
– 通常重放速度约几十 MB/s
– 例如：1024MB 的未 checkpoint 日志，恢复约 10-30 秒

如何确定合适的大小

公式法

推荐大小 = 业务高峰期 1 小时产生的 Redo Log 量

可以通过监控工具或下列 SQL 估算：

-- 查看当前 Redo Log 写入速度
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written';

-- 过几秒再查一次，计算差值
SELECT (innodb_os_log_written_2 - innodb_os_log_written_1) / 3600 AS bytes_per_hour;

经验值

与 Checkpoint 的关系

Checkpoint 是 Redo Log 管理的核心机制：

当前写入位置 (Log sequence number, LSN)
         ↓
┌───────┬────────────────────┬───────────────┐
│ 已刷盘 │  已写 Redo Log    │  可覆盖区域    │
│ 的数据  │  但未刷盘的数据    │              │
└───────┴────────────────────┴───────────────┘
         ↑                     ↑
   Last checkpoint LSN    Log flushed up to

Checkpoint 年龄 = Log sequence number - Last checkpoint at

如果这个差值接近 innodb_log_file_size × innodb_log_files_in_group，说明 Redo Log 空间吃紧，需要调大。

相关配置参数

# Redo Log 文件大小
innodb_log_file_size = 1G

# Redo Log 文件数量
innodb_log_files_in_group = 2

# Redo Log 缓冲区大小
innodb_log_buffer_size = 16M

# 刷新策略
innodb_flush_log_at_trx_commit = 1

innodb_flush_log_at_trx_commit

这个参数决定事务提交时 Redo Log 的写入策略：

生产环境通常建议 =1，除非你能接受最多 1 秒的数据丢失。

MySQL 8.0 Redo Log 的改进

MySQL 8.0.30+ 对 Redo Log 做了架构升级：

1. innodb_redo_log_capacity：动态管理 Redo Log 总量，替代 innodb_log_file_size + innodb_log_files_in_group
2. 自动调整：MySQL 根据当前写入负载自动扩缩 Redo Log 文件
3. 配置示例：

innodb_redo_log_capacity = 2G   # 8.0.30+ 推荐使用

如果设置了 innodb_redo_log_capacity，innodb_log_file_size 和 innodb_log_files_in_group 将被忽略。

最佳实践建议

1. 监控 Checkpoint 年龄：通过 SHOW ENGINE INNODB STATUS 查看
2. 按 1 小时峰值估算大小：确保高峰期不会频繁触发 Checkpoint
3. 修改后需重启：innodb_log_file_size 不能在运行时修改
4. 安全修改步骤：

# 1. 关闭 MySQL
mysqladmin shutdown

# 2. 删除旧 Redo Log 文件
rm /var/lib/mysql/ib_logfile*

# 3. 修改 my.cnf 中的 innodb_log_file_size

# 4. 启动 MySQL（自动创建新的 Redo Log 文件）
mysqld_safe &

面试常问题

Q：innodb_log_file_size 太小会有什么表现？
A：Checkpoint 频率增加，写入吞吐量受限，磁盘 IO 出现周期性的尖刺。SHOW ENGINE INNODB STATUS 中 Log sequence number 和 Last checkpoint at 的差值接近总日志空间。

Q：innodb_flush_log_at_trx_commit 可以设成 2 吗？
A：如果业务可以接受宕机丢失最多 1 秒数据，可以设为 2。但金融、支付等场景必须用 1。

Q：8.0 的 Redo Log 和 5.7 有什么不同？
A：8.0 引入了重新设计的 Redo Log 子系统，支持动态调整容量（innodb_redo_log_capacity），性能更好，管理更方便。8.0.30+ 推荐使用新参数。

Q：崩溃恢复时间怎么估算？
A：恢复时间 ≈ (LSN – Checkpoint LSN) / 重放速度。1GB 的 Redo Log 恢复大概需要 10-30 秒。所以日志设得太大，恢复时间也会变长。