MySQL 8.4中直接迁移使用mysql_native_password的账号会失败，因其插件已被彻底移除而非仅弃用；必须先在源库执行ALTER USER ... IDENTIFIED WITH caching_sha2_password BY 'pwd'重置认证方式，再用SHOW GRANTS导出语句，否则导入后因插件不存在而报错ERROR 1827。
直接迁移 MySQL 8.4 中使用 mysql_native_password 的账号会失败，因为目标库默认只接受 caching_sha2_password 认证方式，且 mysql_native_password 在 8.4 已被彻底移除（不是弃用，是删除）。你必须显式重置认证插件并更新密码哈希，否则 SHOW GRANTS 导出的语句在目标库执行后仍无法登录。
为什么 SHOW GRANTS 导出的语句不能直接用
导出语句如 GRANT SELECT ON mydb.* TO 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; 在 MySQL 8.4 上执行会报错：ERROR 1827 (HY000): Plugin 'mysql_native_password' is not loaded。这是因为：
-
mysql_native_password插件在 8.4 中已从二进制中移除，无法动态加载 -
IDENTIFIED WITH ... BY语法强制要求插件存在，不支持 fallback - 即使你手动插入
mysql.user表，服务启动时也会拒绝加载含无效插件的用户记录
迁移前必须重置账号认证方式
不能跳过这步——所有待迁移账号必须在源库（8.4）上先切换为 caching_sha2_password，再导出权限。操作顺序不可逆：
- 对每个账号执行：
ALTER USER 'user'@'host' IDENTIFIED WITH caching_sha2_password BY 'password'; - 如果账号当前用的是
sha256_password（旧版强密码插件），也需改写，因该插件在 8.4 警告弃用且不兼容新客户端 - 执行后立即验证：
mysql -u user -p -h localhost，确认能连上且SELECT plugin FROM mysql.user WHERE user='user';返回caching_sha2_password - 特别注意：root 或高权限账号若仍用
mysql_native_password，DTS 或 mysqldump 迁移任务本身可能失败，因为迁移工具依赖该账号连接源库
导出权限时要避开 mysql.user 表直写
直接 SELECT * FROM mysql.user 然后 INSERT 到目标库，会导致权限丢失、登录失败甚至系统表损坏。正确做法是：
- 用
SHOW GRANTS FOR 'user'@'host'获取可执行 SQL，它自动适配当前认证插件 - 批量导出脚本必须过滤掉系统账号：
mysql.session、mysql.infoschema、mysql.sys，否则目标库启动异常 - 若账号绑定了角色（
SET DEFAULT ROLE），SHOW GRANTS会一并输出，必须保留；漏掉会导致权限继承失效 - 导出后检查语句是否含
IDENTIFIED WITH caching_sha2_password—— 如果还是mysql_native_password，说明上一步重置没生效
目标库导入后需 FLUSH PRIVILEGES 吗
不需要。MySQL 8.0+ 的权限缓存机制已改为原子化加载，执行 GRANT 或 ALTER USER 后立即生效。但有三个例外：
- 如果你用的是物理拷贝（如复制
mysql系统库文件），必须重启 mysqld 并执行FLUSH PRIVILEGES - 用
INSERT INTO mysql.user直写系统表（严禁这么做），必须FLUSH PRIVILEGES，但大概率触发校验失败 - 目标库版本低于 8.0（比如迁到 5.7），则
caching_sha2_password不识别，此时必须降级插件或换版本
真正容易被忽略的是：迁移后客户端连接字符串必须显式指定 ?serverTimezone=UTC&allowPublicKeyRetrieval=true（尤其 Java 应用），否则首次连接会卡在公钥交换阶段，超时断开。
