MySQL 8.0.30+ 已废弃 innodb_log_file_size，必须改用 innodb_redo_log_capacity 动态调整总容量；若配置文件中仍存在旧参数，启动将失败并报错“Unknown variable”，且 SET GLOBAL 无效。
MySQL 8.0 的 innodb_log_file_size 在 8.0.30+ 版本中已废弃，强行配置会导致启动失败；若你正在用 8.0.30 或更高版本，必须改用 innodb_redo_log_capacity 动态调整总容量，否则服务无法启动。
为什么 SET GLOBAL innodb_log_file_size 失败或启动报错
你在配置文件里写了 innodb_log_file_size，或者执行了 SET GLOBAL innodb_log_file_size = ... —— 这在 MySQL 8.0.30+ 中是非法操作。系统会直接拒绝加载，并报错：Unknown variable 'innodb_log_file_size'。这不是权限或语法问题，而是参数已被硬性移除支持。
- 只要配置文件（
my.cnf）中存在innodb_log_file_size或innodb_log_files_in_group，MySQL 启动时就会校验失败 - 即使只在 session 中 SET，也会被忽略，且错误日志里会出现警告：
[Warning] [MY-013869] Ignored deprecated configuration parameter innodb_log_file_size - 旧日志文件
ib_logfile0/ib_logfile1不再生成；磁盘上看到的是#innodb_redo/#ib_redoN，混用旧路径或残留配置会引发初始化卡死
如何安全迁移到 innodb_redo_log_capacity（8.0.30+）
迁移不是“替换参数”那么简单，而是要清旧、禁用、再启用。漏掉任一环节都可能让实例无法启动。
- 先确认版本：
SELECT @@version;，确保 ≥8.0.30 - 从
my.cnf中彻底删除innodb_log_file_size和innodb_log_files_in_group两行（注释也不行） - 重启 MySQL（这是唯一一次需要停机）：此时 InnoDB 会自动清理旧日志结构，创建
#innodb_redo目录并预分配 32 个#ib_redoN文件 - 检查是否生效：
SELECT @@innodb_redo_log_capacity;（默认 104857600 字节 ≈ 100MB） - 在线扩容（无需再重启）：
SET PERSIST innodb_redo_log_capacity = 2147483648;（2GB）
调整后怎么验证是否真正生效
不能只看变量值，必须核对三处一致性：内存变量、磁盘文件、运行时状态。
- 变量值：
SELECT @@innodb_redo_log_capacity;返回目标字节数 - 重分配完成标志：
SHOW STATUS LIKE 'innodb_redo_log_capacity_resized';返回值应等于变量值（不是 0 或 NULL） - 磁盘文件：
ls -lh #innodb_redo/#ib_redo*，文件总数应为 32 个，每个大小 ≈innodb_redo_log_capacity / 32（如设 2GB，则每个约 64MB） - 监控写入压力：
SELECT * FROM performance_schema.innodb_redo_log_files;可查每个文件的current_lsn、size_bytes和type（ordinary/spare）
容易被忽略的副作用和边界条件
动态调大看似无痛，但两个关键影响常被低估：
- 崩溃恢复时间与
innodb_redo_log_capacity强正相关——设 16GB 容量，宕机重启后重放日志可能耗时数分钟，RTO 直接超标 - 磁盘空间是**立即全量预分配**的：哪怕当前只写入几 KB，32 个文件也会按目标容量一次性占满空间（例如设 4GB，立刻占用 4GB 磁盘）
- 单个文件不可单独控制大小，固定为总容量 ÷ 32；你无法让其中某个
#ib_redo更大或更小 - 如果
innodb_log_group_home_dir被自定义过，必须确保其末尾包含#innodb_redo（如/var/lib/mysql/#innodb_redo），否则启动失败且无明确报错
