MySQL 8.0系统表字典损坏时只能重建而非修复，因其系统表强制使用InnoDB引擎且不支持REPAIR TABLE，mysql_upgrade已被移除，--initialize-insecure可安全重置mysql库而不影响用户数据，但需确认datadir路径、禁用innodb_force_recovery并备份原mysql目录。
MySQL 8.0全新安装后系统表字典损坏，不能修，只能重建——因为InnoDB系统表不支持REPAIR TABLE，mysql_upgrade也早已被移除，唯一安全路径是--initialize-insecure重置系统库。
为什么“重置”比“修复”更合理
MySQL 8.0 的系统表（mysql.user、mysql.db等）全部强制使用 InnoDB 引擎，且字段顺序、索引定义、默认值、数据字典元数据都由服务启动时内核校验。一旦结构错位或元数据缺失（比如plugin字段为空、authentication_string类型不匹配），就会导致：SELECT * FROM mysql.user报Unknown column 'password_last_changed'，或mysqld启动直接失败并提示Data Dictionary initialization failed。这不是权限配置问题，也不是SQL语句写错，是底层字典不一致。此时myisamchk无效（MyISAM已淘汰），REPAIR TABLE报错ERROR 1031 (HY000): Table storage engine for 'user' doesn't support repair，强行用旧版mysql_upgrade只会让字段更乱。
执行--initialize-insecure前必须确认的三件事
该命令会清空mysql系统库，但保留用户数据库（ibdata1、ib_logfile*、所有.ibd文件不受影响）。操作前务必检查：
- 确认
datadir路径正确，且目录下没有残留的mysql/子目录（否则初始化会跳过） - 确保
innodb_force_recovery未启用（若配置文件中存在，先注释掉，否则初始化会被忽略） - 备份原
/var/lib/mysql/mysql/目录（哪怕只是tar -cf mysql-bak.tar mysql/），以防后续需回溯字段定义或角色信息
重建系统库的标准命令与验证步骤
停掉服务后执行：
mysqld --initialize-insecure --datadir=/var/lib/mysql --user=mysql
成功后会生成干净的mysql库，root@localhost密码为空。立即启动服务并验证：
- 用
mysql -u root -p登录（回车跳过密码） - 执行
SELECT user, host, plugin, authentication_string FROM mysql.user WHERE user = 'root';，确认plugin为mysql_native_password（不是auth_socket） - 立刻重设密码：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'your_strong_pwd'; - 运行
FLUSH PRIVILEGES;生效，然后删掉配置里的skip-grant-tables（如有）
重建后仍无法登录？重点查plugin和客户端认证插件
即使mysql.user表结构完整、字段齐全，登录失败大概率是plugin字段值不匹配。比如客户端用mysql_native_password协议连接，但mysql.user里plugin是caching_sha2_password，就会静默拒绝。解决方法：
- 启动时加
--skip-grant-tables进库，手动更新：UPDATE mysql.user SET plugin = 'mysql_native_password', authentication_string = PASSWORD('new_pwd') WHERE user = 'root'; - 或在初始化后首次登录时，用
ALTER USER显式指定插件：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 注意：新版客户端默认尝试
caching_sha2_password，如未适配，连-p参数都输不进去，必须从服务端强制统一
真正麻烦的不是重建本身，而是重建后忘记改密、没清掉skip-grant-tables、或任由plugin字段与客户端协议错配——这些细节一漏，就又回到“能启不能登”的死循环里。
