MySQL 8.0.30+ 默认 innodb_redo_log_capacity 为100MB，远低于生产负载需求，易致checkpoint频繁、Innodb_log_waits上升及大事务卡顿；需根据写入速率（如每秒10MB则建议≥3GB）动态调大并交叉验证变量值、状态值与磁盘文件大小。
MySQL 8.0.30+ 默认的 innodb_redo_log_capacity 是 100MB（104857600 字节），这个值对多数生产写入负载来说太小，不是“必须手动调”，而是“不调就容易出问题”——比如 checkpoint 频繁触发、大事务卡顿、Innodb_log_waits 上升、甚至拖慢主从同步。
为什么默认值撑不住真实业务
100MB 容量对应 32 个文件，每个仅约 3.2MB。实际场景中：
- 一个批量导入事务写入 50MB redo 日志，就会快速填满多个文件，迫使 InnoDB 提前刷脏页，间接拉高
innodb_buffer_pool_wait_free - 若每秒写入量稳定在 10MB，30 秒就写满全部容量，checkpoint age 常超 70%，InnoDB 被动限速
- SSD 环境下虽 IOPS 高，但日志循环过快仍会放大锁竞争（如
log_sys->mutex等待）
SET GLOBAL innodb_redo_log_capacity 失败的常见原因
执行失败不是语法或权限问题，基本都卡在配置冲突上：
- 配置文件（
my.cnf）里还留着innodb_log_file_size或innodb_log_files_in_group——MySQL 启动时直接拒绝加载，报错Unknown variable 'innodb_log_file_size' - 已运行实例中执行
SET GLOBAL没报错但没生效：因为只改内存值，未用SET PERSIST持久化，重启后回落到默认值 -
innodb_log_group_home_dir自定义路径末尾没带#innodb_redo（例如设成/data/redo而非/data/redo/#innodb_redo），导致 MySQL 找不到或无法创建日志目录，启动失败
怎么确认调整真正生效了
别只看变量值，要交叉验证三层状态：
- 查变量：
SELECT @@innodb_redo_log_capacity;—— 确认是目标值（如2147483648） - 查状态：
SHOW GLOBAL STATUS LIKE 'Innodb_redo_log_capacity_resized';—— 返回值必须等于变量值，否则重分配未完成 - 查磁盘：
ls -lh #innodb_redo/#ib_redo*—— 应看到 32 个文件，每个大小 ≈ 总容量 ÷ 32（如 2GB → 每个约 64MB），且无ib_logfile0类旧文件
最常被忽略的是：调大容量不等于性能变好。128GB 容量会让崩溃恢复时间从秒级拉长到分钟级，压测前必须实测 mysqld 重启后的 recovery 耗时。
