删光所有ib_logfile*及#innodb_redo/目录，并清除my.cnf中已弃用的innodb_log_file_size和innodb_log_files_in_group参数，仅保留innodb_redo_log_capacity且确保其目录权限正确，方可解决该启动失败问题。
MySQL启动报InnoDB: Error: log file ./ib_logfile0 is of different size怎么办
这是最典型的非法关机后现象：磁盘上残留的ib_logfile*大小和配置值不一致，InnoDB在初始化阶段直接abort，连数据字典都不加载。不是警告，是硬性拒绝——删文件是唯一解法。
必须进datadir（查SELECT @@datadir;或看my.cnf），执行：rm ib_logfile*
注意：不是只删ib_logfile0和ib_logfile1，所有匹配都要清空。如果存在#innodb_redo/目录（MySQL 8.0.30+），也一并rm -rf #innodb_redo。
删完后跑ls ib_logfile*应返回No such file；ls #innodb_redo同理。
删完文件重启前必须检查的三件事
否则照样启动失败：
- 确认
my.cnf里没留innodb_log_file_size和innodb_log_files_in_group——MySQL 8.0.30+已弃用，留着会触发Unknown variable错误 - 确保只配置了
innodb_redo_log_capacity（且值合理，如100M），其他Redo相关变量全部注释或删除 - 检查
#innodb_redo/目录（若存在）权限：属主必须是MySQL运行用户，且可写；否则InnoDB无法重建日志文件
为什么不能跳过删文件直接改配置
InnoDB启动时读取的是磁盘上真实文件的header，不是配置值。哪怕你把innodb_log_file_size改成128M，只要磁盘上还躺着两个48MB的ib_logfile*，它就会校验失败退出。这不是兼容性问题，是物理结构不匹配——就像拿USB-C线插Micro-USB口，接口对不上就是对不上。
备份ib_logfile*只是为极端情况留底，实际修复中几乎用不到。真正关键的是删干净、配干净、权限干净。
如果删完仍启动失败，大概率是ibdata1损坏
此时innodb_force_recovery=1~6可能有效，但仅用于抢数据，不是修复手段：
- 从
1开始试，1级最安全（跳过未完成事务回滚） -
≥4级会禁用INSERT/UPDATE/DELETE，表自动只读 - 一旦能连上，立刻
mysqldump导出，别等第二次宕机 - 导出后重建实例再导入，不要试图复用旧数据目录
真正容易被忽略的点：ib_logfile*必须全删，#innodb_redo/必须同步清理，配置里不能残留废弃参数——三者缺一不可。任何侥幸都只会让启动卡在同一个错误上。
