<p>MySQL 8.0.30+ 废弃 innodb_log_file_size 是因底层架构强制升级：InnoDB 固定维护32个日志文件（如 #ib_redo31），每个大小 = innodb_redo_log_capacity / 32，仅支持通过该参数在线设总容量（字节），旧参数会导致启动报错“Unknown variable”，且 ib_logfile* 文件已不存在，真实日志位于 #innodb_redo/ 目录。</p>
MySQL 8.0.30+ 的 redo log 文件机制已彻底重构，旧参数 innodb_log_file_size 和 innodb_log_files_in_group 不仅失效，还会导致启动失败；你必须改用 innodb_redo_log_capacity 在线控制总容量，且文件结构、命名、数量全部由 InnoDB 自动管理。
MySQL 8.0.30+ 为什么废掉 innodb_log_file_size？
不是“优化”，而是底层架构强制升级：从 8.0.30 开始，InnoDB 放弃手动管理日志文件个数和单文件大小，转为固定维护 32 个日志文件（如 #ib_redo31、#ib_redo49_tmp），每个文件大小 = innodb_redo_log_capacity / 32。这意味着：
- 你不能再指定“我要两个 2GB 文件”，只能指定“总共要 X 字节”，InnoDB 自动均分
- 配置里若还留着
innodb_log_file_size，mysqld 启动时直接报错：Unknown variable 'innodb_log_file_size'，不是警告，是拒绝启动 - 旧版靠删
ib_logfile0、ib_logfile1手动重建的方式，在 8.0.30+ 完全不适用——那些文件名已不存在，目录变成#innodb_redo/
怎么查当前 MySQL 版本并确认该用哪个参数？
别猜，先执行：
SELECT VERSION();
结果 ≥ 8.0.30？立刻删掉配置文件中所有 innodb_log_file_size 和 innodb_log_files_in_group 行。否则启动必挂。常见误操作：
- 看到文档说“支持在线调整”，就以为旧参数还能用——实际 8.0.30+ 已硬性移除
- 在 8.0.30+ 环境下执行
SHOW VARIABLES LIKE 'innodb_log%'，发现没输出或字段为空——这是正常的，因为参数体系已切换 - 误以为
ls -lh /var/lib/mysql/ib_logfile*还能反映真实状态——这些文件在 8.0.30+ 已被废弃，真正日志在#innodb_redo/目录下
如何安全设置 innodb_redo_log_capacity？
设值单位是字节，不是 MB 或 GB，别换算错：
- 在线临时生效：
SET GLOBAL innodb_redo_log_capacity = 2147483648;（即 2GB） - 持久化到配置文件：
innodb_redo_log_capacity = 2147483648（写入my.cnf的[mysqld]段） - 最小允许值是
1048576（1MB），但 OLTP 场景建议不低于1073741824（1GB） - 执行后无需重启，但底层文件切换是渐进式过程，可能持续数秒至几分钟，期间
performance_schema.innodb_redo_log_files中的type字段会显示ordinary和spare状态交替
容量不是越大越好：设太大（比如 100GB）会导致 checkpoint 推进缓慢，崩溃恢复时间（RTO）飙升；设太小（比如 128MB）则频繁触发刷脏页，拖慢大事务。实操建议用 Innodb_os_log_written 差值估算峰值写入速率，再乘以目标 RTO 时间（如 5 分钟）来反推。
大事务卡顿，真问题是 innodb_log_buffer_size 不足
很多人一遇到大事务提交慢就调 redo 日志大小，其实 90% 是错判。真正瓶颈常在内存缓冲区：
-
innodb_log_buffer_size默认仅 16MB，批量导入百万行或含大 BLOB 时极易撑满 - 表现是
Innodb_log_waits持续上升、TPS 抖动，而非日志循环快 - 调法：从
67108864（64MB）起步，观察Innodb_os_log_written增速是否平稳；单事务日志量超 100MB 可设到134217728（128MB） - 注意：该参数只影响未提交事务的内存缓冲，不影响磁盘日志文件大小，也不放大崩溃丢失风险
真正容易被忽略的是：动态调整 innodb_redo_log_capacity 时，InnoDB 会后台滚动重建日志文件，但这个过程不可中断、不可回退——如果中途磁盘满或进程被 kill，实例可能无法正常关闭，需人工介入清理 #innodb_redo/ 下的临时文件。
