MySQL 8.0.30+ 支持在线调整 redo 日志总容量，需用 innodb_redo_log_capacity 参数，禁用旧参数 innodb_log_file_size 和 innodb_log_files_in_group，否则启动失败或 SET GLOBAL 失效。
MySQL 8.0.30+ 可以在线调整 redo 日志总容量，无需停库、无需删文件、无需改配置文件 —— 但必须用 innodb_redo_log_capacity，不能混用旧参数。
为什么 SET GLOBAL innodb_redo_log_capacity 失败？
常见报错：Unknown variable 'innodb_log_file_size' 或启动失败提示日志文件不匹配，根本原因是：你还在配置文件里写了 innodb_log_file_size 或 innodb_log_files_in_group。
MySQL 8.0.30+ 的规则很明确：
- 只要设置了
innodb_redo_log_capacity，系统就完全忽略innodb_log_file_size和innodb_log_files_in_group - 如果配置文件中同时存在这三者，MySQL 启动时会直接拒绝加载并报错
- 已运行实例中执行
SET GLOBAL innodb_redo_log_capacity = ...失败，大概率是配置文件残留旧参数，或未用SET PERSIST持久化（仅内存生效不等于配置生效）
如何安全地在线调大到 2GB？
确认版本为 8.0.30 或更高（SELECT @@version;），然后分步操作：
- 先检查当前值：
SELECT @@innodb_redo_log_capacity;（默认 104857600 字节 ≈ 100MB） - 在线扩容（立即生效）：
SET GLOBAL innodb_redo_log_capacity = 2147483648;（2GB） - 若需重启后仍保持，加持久化：
SET PERSIST innodb_redo_log_capacity = 2147483648; - 观察状态变量：
SELECT @@innodb_redo_log_capacity_resized;返回 1 表示重分配已完成 - 验证磁盘文件：
ls -lh #innodb_redo/#ib_redo*，应看到约 32 个文件，每个 ≈ 64MB（2GB ÷ 32）
调整后磁盘上看不到 ib_logfile0？这是正常的
8.0.30+ 彻底弃用了 ib_logfile0/ib_logfile1 这类命名，改用 #ib_redoN 文件，全部存放在数据目录下的 #innodb_redo 子目录中。
注意几个关键点：
- 该目录必须由 MySQL 自动创建；手动建目录或改
innodb_log_group_home_dir时路径末尾没带#innodb_redo，会导致启动失败 - 文件分两类：
#ib_redo12是当前活跃日志，#ib_redo12_tmp是待切换的备用日志，不用人工干预 - 总大小严格按
innodb_redo_log_capacity值均分给 32 个文件，哪怕你只写入几百 KB，也会提前预分配全部空间
容易被忽略的副作用和边界
动态调大看似无痛，但实际影响藏在恢复时间和磁盘占用里：
- 崩溃恢复时间与
innodb_redo_log_capacity正相关 —— 设 128GB 容量，启动时重放日志可能耗时数分钟，压测前务必实测 - 磁盘空间不是“按需使用”，而是“一次性预占”：设 10GB 就立刻在
#innodb_redo下生成 32 个约 320MB 的文件（含_tmp），即使业务零写入 - 最小合法值是
1048576（1MB），但低于 100MB 容易触发频繁 checkpoint，SHOW ENGINE INNODB STATUS中 “Log sequence number” 和 “Last checkpoint at” 差值长期 >80% 就是信号 - 如果你从 5.7/8.0.29 升级上来，且原配置含
innodb_log_file_size，升级后首次启动会自动转换日志格式，但此后就不能再回退使用旧参数
