MySQL 5.7及更早版本调整redo日志必须停库删除旧文件后重启，否则因大小不匹配启动失败；8.0.30+改用innodb_redo_log_capacity动态设置总容量，支持在线调整且无需重启。
MySQL 5.7 及更早版本必须停库改配置再重启，否则会报 log file size mismatch；MySQL 8.0.30+ 支持在线调整，用 innodb_redo_log_capacity 替代旧参数，无需重启。
修改 innodb_log_file_size 必须停库，否则启动失败
MySQL 启动时会校验磁盘上已有的 ib_logfile0 和 ib_logfile1 大小是否与配置一致。若不一致，直接拒绝启动，并在错误日志里写明 log file size mismatch。这不是警告，是硬性失败。
- 必须先执行
SET GLOBAL innodb_fast_shutdown = 0，确保所有脏页刷盘、redo 日志落盘完整 - 再停掉 mysqld 进程（
systemctl stop mysqld或kill -15） - 手动移走或重命名旧日志文件：
mv ib_logfile0 ib_logfile0.bak、mv ib_logfile1 ib_logfile1.bak - 改完
my.cnf中的innodb_log_file_size后再启动，InnoDB 才会按新大小重建日志文件
MySQL 8.0.30+ 应该用 innodb_redo_log_capacity，不是 innodb_log_file_size
从 8.0.30 开始，innodb_log_file_size 和 innodb_log_files_in_group 已被废弃。继续在配置文件里写它们，MySQL 启动时会打印警告：Ignored deprecated configuration parameter innodb_log_file_size，且参数无效。
- 新参数
innodb_redo_log_capacity控制总容量（单位字节），比如设为2147483648表示 2GB 总 redo 空间 - 实际生成 32 个固定大小的日志文件，单个大小 =
innodb_redo_log_capacity / 32 - 可在线修改：
SET GLOBAL innodb_redo_log_capacity = 2147483648;，立即生效，无需重启 - 要持久化，需同步写入
my.cnf并删掉旧的两个参数，避免干扰
innodb_log_file_size 太小会导致事务提交变慢
默认值（如 48MB）在高并发写入场景下极易成为瓶颈：日志空间很快填满 → 强制触发 checkpoint → 刷脏页 → 阻塞后续 COMMIT。表现就是应用侧看到 Lock wait timeout exceeded 或明显延迟。
- 观察指标：看
SHOW ENGINE INNODB STATUS输出里的Log sequence number和Last checkpoint at差距是否长期很小（ - 合理范围：按业务每小时写入量估算，常见设为 1G～4G（单文件），总日志空间 ≈ 2～8G
- 别盲目调大：超过 4G 单文件后，崩溃恢复时间显著上升，可能从几秒拉长到分钟级
调整后务必验证日志文件是否真的重建成功
很多人改完配置、重启 MySQL 就以为完成了，但没确认磁盘上的文件是否真按新大小生成。尤其容易忽略的是：如果忘记删旧 ib_logfile*，InnoDB 会沿用旧文件并报错退出；如果误删了但没等 innodb_fast_shutdown = 0 就停库，可能丢失未刷盘事务。
- 启动后立刻检查：
ls -lh ib_logfile*，确认大小和配置一致 - 查运行时值：
SELECT @@innodb_log_file_size;（5.7）或SELECT @@innodb_redo_log_capacity;（8.0.30+） - 留意错误日志是否有
Creating #innodb_redo/目录或Recreating log files类提示
真正麻烦的不是操作步骤，而是判断“当前值是否真不合理”——得结合写入速率、checkpoint 频率、恢复 RTO 要求一起看，不能只盯着一个参数调。
