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 日志总容量，无需停库、无需删文件、无需改配置文件 —— 但必须用，不能混用旧参数。
为什么 SET GLOBAL innodb_redo_log_capacity 失败？
常见报错：
或启动失败提示日志文件不匹配，根本原因是：你还在配置文件里写了
或
。
MySQL 8.0.30+ 的规则很明确：
只要设置了
，系统就完全忽略
和
如果配置文件中同时存在这三者，MySQL 启动时会直接拒绝加载并报错
已运行实例中执行
失败，大概率是配置文件残留旧参数，或未用
持久化（仅内存生效不等于配置生效）
如何安全地在线调大到 2GB？
确认版本为 8.0.30 或更高（
），然后分步操作：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
先检查当前值：
（默认 104857600 字节 ≈ 100MB）
在线扩容（立即生效）：
（2GB）
若需重启后仍保持，加持久化：
观察状态变量：
返回 1 表示重分配已完成
验证磁盘文件：
，应看到约 32 个文件，每个 ≈ 64MB（2GB ÷ 32）
调整后磁盘上看不到 ib_logfile0？这是正常的
8.0.30+ 彻底弃用了
/
这类命名，改用
文件，全部存放在数据目录下的
子目录中。
注意几个关键点：
该目录必须由 MySQL 自动创建；手动建目录或改
时路径末尾没带
，会导致启动失败
文件分两类：
是当前活跃日志，
是待切换的备用日志，不用人工干预
总大小严格按
值均分给 32 个文件，哪怕你只写入几百 KB，也会提前预分配全部空间
容易被忽略的副作用和边界
动态调大看似无痛，但实际影响藏在恢复时间和磁盘占用里：
崩溃恢复时间与
正相关 —— 设 128GB 容量，启动时重放日志可能耗时数分钟，压测前务必实测
磁盘空间不是“按需使用”，而是“一次性预占”：设 10GB 就立刻在
下生成 32 个约 320MB 的文件（含
），即使业务零写入
最小合法值是
（1MB），但低于 100MB 容易触发频繁 checkpoint，
中 “Log sequence number” 和 “Last checkpoint at” 差值长期 >80% 就是信号
如果你从 5.7/8.0.29 升级上来，且原配置含
，升级后首次启动会自动转换日志格式，但此后就不能再回退使用旧参数
innodb_redo_log_capacityUnknown variable 'innodb_log_file_size'innodb_log_file_sizeinnodb_log_files_in_groupinnodb_redo_log_capacityinnodb_log_file_sizeinnodb_log_files_in_groupSET GLOBAL innodb_redo_log_capacity = ...SET PERSISTSELECT @@version;SELECT @@innodb_redo_log_capacity;SET GLOBAL innodb_redo_log_capacity = 2147483648;SET PERSIST innodb_redo_log_capacity = 2147483648;SELECT @@innodb_redo_log_capacity_resized;ls -lh #innodb_redo/#ib_redo*ib_logfile0ib_logfile1#ib_redoN#innodb_redoinnodb_log_group_home_dir#innodb_redo#ib_redo12#ib_redo12_tmpinnodb_redo_log_capacityinnodb_redo_log_capacity#innodb_redo_tmp1048576SHOW ENGINE INNODB STATUSinnodb_log_file_size