MySQL权限表损坏必须按引擎类型修复：MyISAM用myisamchk -r修复，InnoDB/8.0+须--initialize-insecure重建系统库；mysql_upgrade仅升级结构，无法修复物理损坏，且修复后须立即FLUSH PRIVILEGES并移除skip-grant-tables配置。
MySQL安装后权限表损坏，不能靠重装或手建mysql.user解决——表结构、字段顺序、索引、默认值稍有偏差就会导致启动失败或认证逻辑崩溃。必须按引擎类型走对应路径：MyISAM用myisamchk修复，InnoDB/8.0+必须--initialize-insecure重建系统库。
确认是不是真损坏，而不是plugin或密码字段异常
很多“无法登录”根本不是表损坏，只是plugin字段被设成auth_socket或authentication_string为空/格式错乱。先验证：
- 停服务后加
--skip-grant-tables启动，再执行mysql -u root（不加-p）能进就说明表物理结构还在 - 进库后跑
SELECT user, host, plugin, authentication_string FROM mysql.user WHERE user = 'root';，如果返回结果但plugin是auth_socket，那就不是损坏，是认证方式不匹配 - 如果直接报
Table 'mysql.user' doesn't exist或Incorrect information in file: './mysql/user.frm'，才是真损坏
MyISAM权限表（MySQL 5.7及以前）用myisamchk强制修复
老版本默认用MyISAM存系统表，.MYI索引文件损坏最常见。必须停服务后再操作：
- 备份整个
/var/lib/mysql/mysql/目录，别只拷.frm或.MYD - 逐个修复关键表：
myisamchk -r /var/lib/mysql/mysql/user.MYI、myisamchk -r /var/lib/mysql/mysql/db.MYI等 - 若报
key file is old，加-o参数：myisamchk -o -r /var/lib/mysql/mysql/user.MYI - 修完重启，再立刻运行
mysql_upgrade --force补字段和索引，否则新版客户端可能连不上
InnoDB权限表（MySQL 5.7+默认）必须--initialize-insecure重建
REPAIR TABLE mysql.user在InnoDB上必然失败，报错ERROR 1031 (HY000): Table storage engine for 'user' doesn't support repair。此时唯一安全路径是重建系统库：
- 停服务，备份原
/var/lib/mysql/mysql/目录（保留ibdata1和ib_logfile*） - 执行初始化：
mysqld --initialize-insecure --datadir=/var/lib/mysql --user=mysql（路径按实际改） - 启动后立刻用空密码登录：
mysql -u root -p（回车），然后重设密码：ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_pwd'; -
--initialize-insecure不生成随机密码，root@localhost默认空密码，务必第一时间改密
mysql_upgrade不是修复工具，别指望它救火
mysql_upgrade不能修复已损坏的权限表，仅能升级可正常读取的系统库结构。如果mysql.user已崩溃，它会直接报错退出，甚至可能因元数据不一致导致后续启动失败。
- 常见错误现象：
mysql_upgrade启动后立刻报Failed to open mysql.user或Incorrect information in file: './mysql/user.MYI' - 根本原因：
mysql_upgrade依赖MySQL能正常加载系统库元数据；一旦.frm、.MYI或.ibd损坏或缺失，它连表结构都解析不了 - 误删
/var/lib/mysql/mysql/下任意一个文件（哪怕只是user.frm），都可能导致整个系统库不可识别
真正容易被忽略的是：修复后没立刻执行FLUSH PRIVILEGES，或者忘了删掉配置文件里的skip-grant-tables和skip-networking——这会让实例长期处于无权限验证状态，风险极高。
