不能只改innodb_log_file_size就重启，否则MySQL启动失败；因为InnoDB启动时会校验ib_logfile*大小是否与配置值一致，不匹配则报错“InnoDB: Error: log file ./ib_logfile0 is of different size”并退出。
直接结论：不能只改 innodb_log_file_size 就重启，否则 MySQL 启动失败。
为什么改完 innodb_log_file_size 会启动报错？
InnoDB 启动时校验所有 ib_logfile* 文件大小是否与配置值一致。如果配置文件里写了 innodb_log_file_size = 512M，但磁盘上还留着旧的 48MB 的 ib_logfile0 和 ib_logfile1，就会报错：
InnoDB: Error: log file ./ib_logfile0 is of different size
这不是警告，是致命错误，MySQL 进程直接退出。
常见误操作包括：
- 只改了
my.cnf，没删旧日志文件 - 删了
ib_logfile*但没停库（Linux 下可能被 mysqld 持有句柄，rm只是 unlink，文件实际还在） - 删完后没清空
innodb_log_files_in_group对应数量的文件（默认是 2 个，必须都删）
安全扩容 redo log 的完整步骤
必须按顺序执行，跳步或并行操作大概率导致实例不可用：
- 确认当前配置：
SHOW VARIABLES LIKE 'innodb_log_file_size';和SHOW VARIABLES LIKE 'innodb_log_files_in_group'; - 关闭 MySQL：
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中的[mysqld]段，写入新值，例如：innodb_log_file_size = 512M - 启动 MySQL：
sudo systemctl start mysql
注意：innodb_log_file_size 值必须是 512KB 的整数倍，且不能超过 innodb_redo_log_capacity（MySQL 8.0.30+）的限制。
改多大才合适？看写入压力，不是拍脑袋
盲目设成 2G 或 4G 反而有害：崩溃恢复时间线性增长，且 checkpoint 频率过低会导致脏页堆积、Buffer Pool 命中率下降。
推荐估算方式：
- 查最近一小时最大每秒写入量：
SHOW ENGINE INNODB STATUS\G中找Log sequence number差值 ÷ 3600 - 目标日志容量至少撑住 10–20 秒写入峰值（例如峰值 120MB/s，则
innodb_redo_log_capacity ≥ 2.4GB） - 若用的是 MySQL 8.0.30+，优先调
innodb_redo_log_capacity（动态可调），它会自动管理多个日志文件；老版本才必须调innodb_log_file_size
典型生产值范围：写入中等（TPS 500–2000）用 256M–512M；高写入（TPS > 5000）可到 1G，但务必配合监控 Log checkpoint age 是否稳定在阈值内。
改完之后必须验证的三件事
别以为启动成功就万事大吉：
- 确认生效：
SHOW VARIABLES LIKE 'innodb_log_file_size';输出值必须和配置一致 - 检查日志循环：
SHOW ENGINE INNODB STATUS\G中LOG段的Log sequence number和Log flushed up to应持续增长，且差值稳定（说明没 stall） - 观察卡顿是否消失：重点看
SHOW PROCESSLIST中是否有大量update/insert状态卡在query end或ending statements—— 这是 redo log 写满的典型表现
最容易被忽略的一点：扩容只是治标。如果 innodb_flush_log_at_trx_commit = 1 + 机械盘 + 高频小事务，再大的 redo log 也会频繁触发 checkpoint。真正要调的，往往是刷盘策略和写入模式本身。
