MySQL 8.0.30+ 初始化必须用 innodb_redo_log_capacity，禁用 innodb_log_file_size；该参数设总容量（字节），支持在线调整，需结合写入峰值与RTO计算合理值（如120MB/s×300s≈36.9GB），并同步配置 innodb_log_buffer_size（建议64MB起）以避免大事务内存瓶颈。
MySQL 8.0 初始化时必须用 innodb_redo_log_capacity，别写 innodb_log_file_size
MySQL 8.0.30+ 初始化时，innodb_log_file_size 已被移除，硬写进去会导致 mysqld 启动失败并报错：Unknown variable 'innodb_log_file_size'。你只能在配置文件里设 innodb_redo_log_capacity（单位字节），且该参数支持初始化后在线调整，无需重启。
常见错误现象：初始化后启动失败，日志里出现 “Unknown variable” 或 “Ignored deprecated configuration parameter”；或初始化成功但后续 SET GLOBAL innodb_redo_log_capacity 报错 —— 很可能是配置文件里混写了旧参数。
- 初始化前清空 my.cnf 中所有
innodb_log_file_size、innodb_log_files_in_group行 - 只保留一行：
innodb_redo_log_capacity = 2147483648（即 2GB） - 该值代表 Redo Log 总容量，InnoDB 会自动拆成约 32 个文件（如
#ib_redo0～#ib_redo31），每个大小 ≈ 总容量 ÷ 32 - 初始化命令（如 mysqld --initialize）不读取运行时 SET 值，只认配置文件，所以必须提前写好
初始化前怎么定 innodb_redo_log_capacity 的合理值？
不是拍脑袋填个 1G 或 4G，而是按业务写入峰值和 RTO（崩溃恢复时间目标）反推。比如你的批量导入峰值写入速率为 120 MB/s，要求崩溃后 5 分钟内恢复，则总容量至少要撑住 5×60×120×1024×1024 ≈ 36.9GB（即 innodb_redo_log_capacity = 38654705664）。
但注意：这个值不是越大越好。实测发现，超过 64GB 后，崩溃恢复时间增长非线性，且对 SSD 随机读压力陡增；而低于 2GB，在 OLTP 场景下容易触发频繁 checkpoint，表现为 Innodb_os_log_written 每秒增量剧烈抖动。
- OLTP 常见安全区间：2GB～8GB（对应
2147483648～8589934592） - 高吞吐 ETL 场景：从 16GB 起步，但务必压测启动耗时（
mysqld加载 redo 并重放的时间） - 初始化后立刻查实际值：
SELECT @@innodb_redo_log_capacity; - 别依赖
ls -lh #ib_redo*看文件大小 —— 文件名和数量由 InnoDB 动态管理，单个文件大小不等于配置值
初始化时漏配 innodb_log_buffer_size 会导致大事务卡顿
很多人只调大 Redo Log 容量，却忽略 innodb_log_buffer_size。它控制事务未提交前 redo 日志在内存里的缓冲区，默认仅 16MB。当单事务产生超 100MB redo（如含 BLOB 的百万行 INSERT），缓冲区反复满溢、刷盘、拷贝，直接拖慢 TPS，Innodb_log_waits 持续上升 —— 这和磁盘日志文件大小无关，纯内存瓶颈。
初始化时就该一起配好，否则上线后才发现性能问题，还得额外停机改配置（该参数支持 SET GLOBAL 在线调，但初始值影响 buffer 分配时机）。
- 建议起步值：
innodb_log_buffer_size = 67108864（64MB） - 若已知有超大事务，直接设为
134217728（128MB） - 别设到 512MB 以上 —— 内存占用翻倍，但收益几乎为零，还可能挤占 Buffer Pool
- 验证方式：
SHOW VARIABLES LIKE 'innodb_log_buffer_size';，再跑一个大事务看SHOW STATUS LIKE 'Innodb_log_waits';是否归零
初始化后第一件事：确认 Redo Log 实际状态
初始化完成不代表配置生效。MySQL 8.0.30+ 的 Redo Log 是惰性创建的，首次写入才真正生成文件。如果初始化后没写数据，performance_schema.innodb_redo_log_files 可能为空，SELECT @@innodb_redo_log_capacity 却返回正确值 —— 这是正常现象，别误判失败。
真正要盯的是日志循环是否健康：连续执行两次 SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_os_log_written';，间隔 30 秒，差值 ÷ 30 得出当前写入速率；再结合 SELECT * FROM performance_schema.innodb_redo_log_files; 查 type = 'ordinary' 的文件数和 space_used_percent，若后者长期 > 70%，说明容量还是偏小。
- 别用
ls -lh ib_logfile*—— 8.0.30+ 根本不生成这个名字的文件 - 别信启动日志里 “Redo log initialized” 就万事大吉，得看真实写入行为
- 如果初始化后立即执行大事务失败，先检查
innodb_log_buffer_size是否太小，而不是急着调innodb_redo_log_capacity
