mysql 8.0 删除 ib_logfile0/ib_logfile1 后无法启动，因其启动时强制校验文件存在性与尺寸是否匹配 innodb_log_file_size，缺失或不一致即硬性中止；该日志环含 checkpoint 元数据和未刷盘变更，不可缺失或重建，必须干净停机后删除并重启由 innodb 自动创建。
MySQL 8.0 删除 ib_logfile0 和 ib_logfile1 后无法启动，不是配置错了，也不是权限问题，而是 InnoDB 启动时强制校验这两个文件的存在性与尺寸——缺一个、小一点、大一点，都会直接报错退出。
为什么删了就起不来？InnoDB 的重做日志环不可“空缺”
InnoDB 把 ib_logfile0 和 ib_logfile1 当作一个固定大小的循环写入日志环（redo log ring），里面存着未刷盘的脏页变更和上一次 checkpoint 的元数据。它不是纯追加日志（如 mysql-bin.000001），不能靠重放重建；缺失即意味着崩溃恢复上下文丢失，InnoDB 宁可拒绝启动也不冒险。
常见错误现象包括：
InnoDB: Error: log file ib_logfile0 is of different sizeInnoDB: Cannot initialize InnoDB due to missing log files- 启动卡在
Initializing buffer pool之后，无后续日志输出
安全重启的唯一路径：干净停机 + 配置对齐 + 让 InnoDB 自建
必须满足三个条件才能让 MySQL 8.0 自动重建日志文件：
- 数据库已完全停止（
systemctl stop mysql或mysqladmin shutdown），且 error log 最后一行是Shutdown completed -
innodb_log_file_size值未被意外修改（改过就必须删；没改却删了，重启仍会校验失败） - 确保
innodb_log_group_home_dir指向正确路径——默认是datadir，但若自定义过，ib_logfile*实际不在/var/lib/mysql/下，删错位置等于白删
操作顺序严格为：
1. 确认进程已退出：pgrep mysqld 返回空
2. 检查 error log 结尾是否含 Shutdown completed
3. 执行 rm -f /var/lib/mysql/ib_logfile*（或按 innodb_log_group_home_dir 路径删）
4. 启动：systemctl start mysql —— 此时 InnoDB 会按当前 innodb_log_file_size 创建新文件
Docker / systemd 环境下最容易踩的坑
很多“删完重启失败”的案例，根本不是 InnoDB 本身的问题，而是环境假停机：
- Docker 容器里用
kill -9或docker kill，MySQL 进程没走正常 shutdown 流程，ib_logfile*虽被删，但残留的pid文件或 socket 导致 systemd 认为服务还在运行 - systemd 启动脚本中未设置
Restart=on-failure，或TimeoutSec过短，导致启动超时被强杀，日志里只看到 “Starting…” 就断了 - 删完日志后没清
/var/run/mysqld/mysqld.pid，下次启动因 pid 文件存在而拒绝初始化
务必先看 /var/lib/mysql/hostname.err（Linux）或 data\*.err（Windows）最后一段报错——它几乎总能告诉你到底是校验失败、路径不对，还是根本没真正停机。
千万别碰 ibdata1，也别信“删完就能启动”
有人误删 ib_logfile* 后顺手把 ibdata1 也删了，发现 MySQL 真能启动，但所有表 SHOW TABLES 可见、SELECT 却报 Table doesn't exist。这是因为 ibdata1 存着 InnoDB 的数据字典（表结构元数据），删了它等于丢了“目录”，表空间文件（.ibd）还在也没用。
如果你只删了 ib_logfile*，但 ibdata1 和各库下的 .ibd 都完好，且 MySQL 是干净关闭的，那重建日志后数据可完整恢复；一旦 ibdata1 没了，哪怕表文件全在，也得靠可传输表空间（ALTER TABLE ... DISCARD/IMPORT TABLESPACE）逐个救，前提是你有原表结构 DDL。
