修改 innodb_log_file_size 必须停库重启，因该参数为静态配置，运行中不可动态修改；否则启动时会因日志文件大小不匹配报错“innodb: error: log file ./ib_logfile0 is of different size”。
修改 innodb_log_file_size 前必须停库，不能动态生效
MySQL 的 innodb_log_file_size 是 InnoDB 启动时读取的静态参数，运行中无法通过 SET GLOBAL 修改。强行改配置文件后不重启，InnoDB 会直接拒绝启动，并报错：InnoDB: Error: log file ./ib_logfile0 is of different size。
实操建议：
- 先确认当前 Redo Log 文件实际大小：
ls -lh ib_logfile*（在 MySQL 数据目录下） - 检查当前配置值：
SHOW VARIABLES LIKE 'innodb_log_file_size'; - 停掉 MySQL：
systemctl stop mysqld或mysqladmin shutdown - 备份原有日志文件（别直接删！）：
mv ib_logfile0 ib_logfile0.bak、mv ib_logfile1 ib_logfile1.bak - 修改
my.cnf中的innodb_log_file_size，例如设为256M
Redo Log 总大小 = innodb_log_files_in_group × innodb_log_file_size
很多人只调 innodb_log_file_size，却忽略 innodb_log_files_in_group（默认是 2）。真正影响写入吞吐和崩溃恢复时间的是总容量。比如设 innodb_log_file_size = 512M 但 innodb_log_files_in_group = 2，等效于 1G 总空间；而设成 1G + 1，也是 1G，但单个文件更大，可能加剧 checkpoint 压力。
常见错误现象：
- 调大单个文件但没调组数，结果总空间没变，写满更快 → 出现频繁
Waiting for query cache lock或慢查询堆积 - 调小后总空间过小（如
- 升级 MySQL 版本后，默认
innodb_log_files_in_group可能从 2 变成 1（如某些 8.0.30+ 行为），导致总空间腰斩
调整后首次启动失败？大概率是文件残留或权限问题
InnoDB 启动时会校验日志文件数量、大小、checksum。哪怕只多一个字节、少一个文件、属主不对，都会卡在初始化阶段，错误日志里反复出现：InnoDB: The log sequence number in ibdata files does not match 或更直白的：InnoDB: Cannot open ./ib_logfile0。
实操建议：
- 确保
ib_logfile*全部移走或删干净（不是 rename 后留着） - 确认 MySQL 进程用户（如
mysql）对数据目录有读写权限：ls -ld /var/lib/mysql - 启动时加
--innodb-force-recovery=1是无效的 —— Redo Log 初始化失败发生在 recovery 阶段之前 - 如果启不来，临时把
innodb_log_file_size改回原值，先让实例起来，再找空闲窗口重试
线上环境调大 Redo Log 的真实代价：不只是磁盘空间
增大 Redo Log 能降低 checkpoint 频率、提升写吞吐，但也会拉长崩溃恢复时间 —— MySQL 重启时要重放所有未刷盘的 Redo 记录。1G 日志在高压力下可能积压几秒到几十秒的事务，恢复就可能耗时数分钟。
使用场景提醒：
- OLTP 系统写入密集（如订单、支付）：推荐总大小 1G–4G，视
innodb_buffer_pool_size比例而定（通常 25% 左右较稳） - SSD 磁盘可适当放大（如 4G），但 HDD 上超过 2G 可能因顺序写瓶颈反而拖慢
- 容器化部署要注意：
ib_logfile*不在 volume 里？改完配置启动失败时，日志文件可能生成在临时路径，导致下次启动又找不到
最常被跳过的一步：改完配置、删完旧日志、重启成功后，立刻执行 SHOW ENGINE INNODB STATUS\G，翻到 LOG 小节，核对 Log sequence number 和 Log flushed up to 是否正常推进 —— 别只看“启动成功”就以为万事大吉。
