必须删除datadir下所有ib_logfile*及#innodb_redo目录，注释废弃参数innodb_log_file_size和innodb_log_files_in_group，确保仅配置innodb_redo_log_capacity且目录可写，再重启MySQL。
为什么改了innodb_log_file_size重启就失败？
不是配置没生效，是InnoDB启动时会严格校验磁盘上ib_logfile0和ib_logfile1的实际大小是否与my.cnf里写的innodb_log_file_size一致。不匹配直接报错退出：InnoDB: Error: log file ./ib_logfile0 is of different size。
常见踩坑点：
- 只改配置、没删旧日志文件
- 删文件前没停库，Linux下
rm只是unlink，mysqld进程仍持有句柄，文件实际还在 - 只删了一个
ib_logfile0，漏掉ib_logfile1（默认innodb_log_files_in_group = 2）
安全扩容Redo Log的实操步骤（MySQL 5.7必须停库）
MySQL 5.7不支持在线调整，必须按顺序执行，跳步等于实例宕机：
- 确认当前值：
SHOW VARIABLES LIKE 'innodb_log_file_size';和SHOW VARIABLES LIKE 'innodb_log_files_in_group'; - 停库：
sudo systemctl stop mysql，再用ps aux | grep mysqld确认进程已消失 - 检查残留句柄：
lsof -p $(pgrep mysqld) 2>/dev/null | grep ib_logfile，输出为空才安全 - 删除日志：
rm /var/lib/mysql/ib_logfile*（路径以datadir为准） - 修改
my.cnf，例如写入：innodb_log_file_size = 512M（必须是512KB整数倍） - 启动：
sudo systemctl start mysql
innodb_log_file_size设多大才算够？
不能拍脑袋定。关键看业务峰值写入压力：
- 查最近10秒
Innodb_os_log_written增量：SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_os_log_written';，连查两次算差值 - 单个文件建议1–2GB，总容量（
innodb_log_file_size × innodb_log_files_in_group）至少覆盖15–30分钟峰值写入量 - 如果业务含大事务（如批量DELETE 500万行），小日志会卡在提交阶段——因为整个事务的redo必须一次性刷盘，buffer不够就等I/O，表现就是事务hang住
- 搭配
innodb_flush_log_at_trx_commit = 2时，innodb_log_file_size至少2GB，否则断电可能丢1秒以上数据
扩容后怎么验证是否真生效？
别只看启动成功，重点盯两个指标：
- 运行
SHOW ENGINE INNODB STATUS\G，看LOG部分：Log sequence number和Last checkpoint at的差值，健康水位应在总日志容量的30%–50% - 监控
Innodb_log_waits，如果持续>0，说明innodb_log_buffer_size也得调大（建议32–64MB） - 观察
Innodb_buffer_pool_pages_dirty是否不再高位震荡——频繁checkpoint缓解了，脏页刷盘才真正平滑
最易被忽略的是：扩容后crash recovery时间会变长，但日常写入延迟下降明显；线上操作前务必先在备库验证，别拿主库练手。
