mysql 8.0.30+ 必须用 innodb_redo_log_capacity，低于该版本才需停库删 ib_logfile* 并改 innodb_log_file_size；配错会导致启动失败或崩溃恢复超时，必须根据 select version() 结果严格区分参数使用，再结合写入速率与 rto 合理计算容量并三重验证生效。
直接结论：MySQL 8.0.30+ 必须用 innodb_redo_log_capacity，且值不能拍脑袋填；低于 8.0.30 才需停库删 ib_logfile0 并改 innodb_log_file_size。配错不是性能差一点，而是启动失败或崩溃恢复超时。
怎么看自己该用哪个参数
先执行 SELECT VERSION();，结果决定一切：
- ≥ 8.0.30：只认
innodb_redo_log_capacity，配置文件里出现innodb_log_file_size就报错Unknown variable 'innodb_log_file_size' - ≤ 8.0.29：必须用
innodb_log_file_size×innodb_log_files_in_group（默认为 2）算总大小，改完不删旧日志文件，启动直接卡在InnoDB: Error: log file ./ib_logfile0 is of different size - 升级到 8.0.30+ 后残留旧参数？启动时会打警告
[Warning] [MY-013869] Ignored deprecated configuration parameter innodb_log_file_size，但变量仍无效
怎么算出合理的 redo log 总容量
不是“越大越好”，而是让 checkpoint age（Log sequence number − Last checkpoint at）稳定在总容量的 70% 以下。超过就说明刷脏页太频繁，大事务会被拖慢。
- 查当前写入速率：
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_os_log_written';，隔 30 秒再查一次，差值 ÷ 30 → 得到每秒字节数 - 按业务可接受的 checkpoint 缓冲时间反推：比如峰值写入 12MB/s，希望缓冲 5 分钟，则总容量 ≥
12 * 1024 * 1024 * 300 ≈ 3.6GB（即3865470566字节） - OLTP 场景安全区间是 2GB～8GB；ETL 或批量导入场景建议从 16GB 起步，但要压测崩溃恢复时间——超过 64GB 后恢复耗时非线性增长
- 别忽略
innodb_log_buffer_size：大事务卡顿常因它太小（默认 16MB），而不是 redo log 文件不够大。单事务日志常超 100MB？先调到134217728（128MB）试试
怎么安全修改并验证生效
8.0.30+ 支持在线调整，但“在线”不等于“无感知”。底层文件切换是渐进式，可能持续数秒到几分钟，期间监控不可断。
- 持久化配置：在
/etc/my.cnf（Linux）或my.ini（Windows）中只留一行：innodb_redo_log_capacity = 2147483648（2GB），删掉所有innodb_log_file_size和innodb_log_files_in_group - 在线扩容（无需重启）：
SET PERSIST innodb_redo_log_capacity = 2147483648;，之后查SHOW STATUS LIKE 'innodb_redo_log_capacity_resized';，返回值应等于目标值才表示重分配完成 - 验证三处一致性：
SELECT @@innodb_redo_log_capacity;（内存）、ls -lh #innodb_redo/#ib_redo*（磁盘，应有 32 个文件，每个 ≈ 总容量 / 32）、SELECT * FROM performance_schema.innodb_redo_log_files;（运行时状态） - 切忌用
ls -lh ib_logfile*验证——8.0.30+ 已不用这个名字，旧命令看到的是空或残留文件
最容易被忽略的点：很多人调大了容量却没观察 innodb_redo_log_capacity_resized 状态，误以为已生效；或者压测时只看 TPS，却漏掉了崩溃恢复时间翻倍的风险。redo log 不是调完就完事，它和 innodb_flush_log_at_trx_commit、磁盘 I/O 能力强绑定，得一起看。
