mysql 8.0升级后无法登录等问题根源是系统库结构未适配，mysql_upgrade自8.0.16起已被彻底移除，修复须停服后用同版本干净实例导出mysql库结构（mysqldump --no-data）替换损坏目录，并启动自动升级逻辑。
MySQL 升级到 8.0 后无法登录、Access denied、SELECT USER() 返回空、甚至 mysql.user 表字段缺失或报错 —— 这些都不是密码错了，而是系统库结构没对齐。直接拷贝旧 mysql 目录或用 mysqldump --all-databases 导入权限表，90% 会失败。
为什么 mysql_upgrade 不起作用甚至报错？
MySQL 8.0.16 起官方已彻底移除 mysql_upgrade 工具。它不是“升级后忘了跑”，而是内核不再支持——启动时自动完成数据字典升级，人工运行只会触发 command not found 或静默跳过，严重时还可能破坏元数据。
常见误操作包括：
- 在 Docker 容器里挂载了宿主机的旧版
mysql_upgrade，结果执行时报Failed to open mysql.component table - 看到
This installation of MySQL is already upgraded就以为万事大吉，但实际authentication_string字段仍是空的 - 升级失败后反复重试，日志末尾的
ERROR 1878 (HY000)指向innodb_index_stats创建失败，根源是权限表结构未就绪
如何验证 mysql.user 表是否真正适配 8.0？
连得上（比如用 --skip-grant-tables 启动后进库）不代表结构正确。必须查字段和值：
- 执行
SELECT User, Host, plugin, authentication_string FROM mysql.user LIMIT 1;—— 如果报Unknown column 'plugin'或字段全为空，说明还是 5.7 结构 -
plugin值应为caching_sha2_password或mysql_native_password；若为''或mysql_old_password，认证必然失败 -
authentication_string必须非空；Password字段在 8.0 中已彻底删除，任何残留该字段的 SQL 都会导入失败
修复权限表结构的唯一可靠路径
不要试图 INSERT 旧数据、不要 dump 整个 mysql 库、不要依赖 mysql_upgrade。正确顺序是：
- 停掉
mysqld，确认无残留进程：ps aux | grep mysqld - 备份原
/var/lib/mysql/mysql/目录（含所有.ibd和.sdi文件），重命名为mysql_bak_20260609 - 用同版本干净实例导出结构：
mysqldump --no-data --skip-triggers --skip-routines mysql > mysql_struct.sql - 用该 SQL 替换损坏的
mysql目录下所有表定义（保留ibdata1、日志文件等数据文件） - 启动服务，让
mysqld自动完成首次升级逻辑：填充password_last_changed、重建视图、校验authentication_string格式
修复后仍无法登录？重点盯 plugin 和客户端兼容性
即使结构正确，root@localhost 也可能因插件不匹配被拒。此时不能只改密码：
- 先用
mysql -u root -p --default-auth=mysql_native_password强制指定插件登录 - 登录后立刻执行：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_strong_pwd'; FLUSH PRIVILEGES; - 检查应用连接字符串是否带
?serverTimezone=UTC&allowPublicKeyRetrieval=true等 JDBC 8.0 必需参数 - 老旧 PHP 或 Navicat 若连不上，别急着降级插件——先升级驱动，
caching_sha2_password是安全底线
最易被忽略的一点：修复不是“跑完命令就结束”。你得确认 mysql.user 的每一行都通过了新版本的校验逻辑，而不仅是字段存在。字段齐全 ≠ 值合法，值合法 ≠ 插件被客户端识别。每一步都要用真实连接验证，而不是只看 SHOW GRANTS 输出。
