mysql 8.0升级后必须显式执行alter user ... identified with重置plugin字段，因旧用户不会自动适配新认证插件；default_authentication_plugin配置对已有用户无效，客户端驱动版本兼容性比sql层修复更关键。
ALTER USER 必须显式重置已有用户的 plugin 字段
MySQL 8.0 不会自动把 5.7 用户的 mysql_native_password 认证方式“升级”成新插件，但也不会保留旧逻辑——它直接按密码哈希格式反推认证插件。如果用户是 5.7 创建的，其 plugin 字段在 8.0 的 mysql.user 视图里仍显示为 mysql_native_password，但启动后可能因权限校验路径变化而拒绝连接。
真正起作用的是 ALTER USER ... IDENTIFIED WITH 语句，它强制覆盖哈希存储格式和插件绑定：
- 必须用 root 或具有
CREATE USER权限的账号执行，不能靠改配置文件 - 语句必须包含完整主机名，如
'app_user'@'10.20.%'，不能只写'app_user'@'%'（若原定义更精确） - 如果用户密码为空或弱密码，MySQL 8.0 可能拒绝执行，需先
SET PASSWORD设强密码再改插件 - 执行后必须
FLUSH PRIVILEGES，否则部分连接池不会立即感知变更
default_authentication_plugin=my.cnf 配置项对升级无效
my.cnf 中的 default_authentication_plugin=mysql_native_password 只在实例首次初始化（mysqld --initialize）时生效，升级后的实例修改该参数完全不改变任何已有用户的认证行为。
常见误操作是：升级后改了配置、重启、以为问题解决，结果应用仍连不上——因为日志里根本不会报错，只是客户端协商失败静默断开。
验证方式很简单：
- 运行
SELECT User, Host, plugin FROM mysql.user WHERE plugin != 'mysql_native_password'; - 如果返回非空，说明这些用户仍用
caching_sha2_password，配置文件改动没起作用 - 不要查
@@default_authentication_plugin，它只反映新用户默认值，与现有用户无关
客户端驱动版本比 SQL 层修复更关键
即使所有用户都已 ALTER USER 成功，老客户端仍可能在特定场景下失败：长连接复用、连接池预热、SSL 握手阶段。根本原因是驱动本身不支持 caching_sha2_password 协议握手流程。
关键兼容底线如下：
- Java：必须用
mysql-connector-java≥ 8.0.13；8.0.12 是最低可用版，但存在allowPublicKeyRetrieval=true绕过漏洞 - Python：
PyMySQL≥ 1.0.2 或mysql-connector-python≥ 8.0.12；MySQLdb永远不支持，别试 - PHP：
mysqli扩展需 PHP ≥ 7.4 + mysqlnd ≥ 8.0.0；pdo_mysql同理 - Navicat / DBeaver：必须 ≥ 15.x 版本，旧版即使输对密码也卡在“Authenticating…”
系统库迁移时 mysql.user 表不能被覆盖或导入
最隐蔽的权限故障不是用户连不上，而是 root 自己连不上——往往因为误把 5.7 的 mysql 库整个导出再导入到 8.0。
8.0 的 mysql.user 已是视图，底层由 mysql.global_grants、mysql.role_edges 等新表支撑，字段结构完全不同（例如删掉了 Password，新增 account_locked）。强行导入会导致：
-
mysqld启动失败，报Table 'mysql.user' doesn't exist或Unknown table 'mysql.role_edges' - 即使启动成功，
SHOW GRANTS返回空或乱码，CREATE USER报错 - 修复代价极高：必须停服、用
mysqld --upgrade=FORCE强制重建系统表，且期间无法访问任何权限相关元数据
正确做法是：只导出业务库，绝不碰 mysql、information_schema、performance_schema、sys 这四个库。
