MySQL启动失败主因是mysql库权限表损坏或字段缺失，需以--skip-grant-tables免验证模式修复数据；errno 13常为权限系统未就绪的副作用，非真实文件权限问题；修复后仍abort则可能因mysql.ibd损坏或InnoDB行格式不兼容，须检查并重建系统表空间。
MySQL因系统表权限丢失而启动失败，本质是mysql库中user、global_grants等权限表数据损坏或字段缺失，导致服务校验阶段直接abort。不能靠重启或改配置解决，必须进入免验证模式修复数据本身。
看到 os errno 13 - permission denied 却不是文件权限问题？
错误日志里出现mysqld: file './binlog.index' not found (os errno 13 - permission denied)，但ls -l /usr/local/var/mysql/显示目录权限正常——这往往不是磁盘权限错了，而是MySQL在初始化时读取mysql.user表失败，无法确认自己该以哪个用户身份运行，进而放弃创建临时文件。此时errno 13是“权限系统未就绪”的副作用，不是根源。
- 先停掉所有
mysqld进程：sudo pkill mysqld（避免残留实例干扰） - 用
--skip-grant-tables启动，但必须加--skip-networking防未授权访问：sudo mysqld --skip-grant-tables --skip-networking & - 立刻连接：
mysql -u root（此时无密码，也不校验权限）
FLUSH PRIVILEGES 执行后仍报 Access denied？
连进去了，执行FLUSH PRIVILEGES，再试USE mysql还是被拒，说明mysql库本身结构异常：比如MySQL 8.0的user表含password_history字段，而你用5.7备份还原过，字段缺失会导致权限加载中断。
- 检查当前是否真跳过了权限：
SELECT @@skip_grant_tables;返回1才有效 - 查
user表字段完整性：DESCRIBE mysql.user;对比[官方文档对应版本字段列表](https://dev.mysql.com/doc/refman/8.0/en/mysql-system-schema.html)，缺字段必须重建 - 别手写
UPDATE user SET ...补权限——字段不全时SQL会静默失败；改用ALTER USER 'root'@'localhost' IDENTIFIED BY 'xxx';触发内部权限重载逻辑
修复后重启仍卡在 Aborting？检查 datadir 下的 ibdata1 和 mysql.ibd
权限表数据修好了，但InnoDB引擎加载mysql系统表空间时发现mysql.ibd物理文件损坏或ibdata1头信息不一致，就会再次abort。这不是权限问题，是存储层故障。
- 启动前先确认
datadir下mysql子目录存在且非空：ls -la /usr/local/var/mysql/mysql/ - 若
mysql.ibd大小为0或报InnoDB: Operating system error number 2，说明文件已损，需从备份恢复整个mysql库（不是只导user表） - 没有备份时，可尝试用
mysqld --initialize-insecure --datadir=/usr/local/var/mysql重建空白系统库，再手动导入你修复好的user、db等表数据（注意字符集和行格式匹配）
最易被忽略的一点：MySQL 8.0+ 的mysql库默认使用COMPACT行格式，但如果你从老版本迁移过来，mysql.ibd可能是REDUNDANT格式，InnoDB拒绝加载——这种情况下SHOW TABLES都执行不了，必须重建或转换格式。
