直接导出 mysql.user 表会出错，因版本间结构差异、字段依赖运行时状态及8.0+ caching_sha2_password插件兼容性问题；应使用 SHOW GRANTS FOR 逐个生成授权语句迁移。
直接导出 mysql.user 表会出错，别这么做
MySQL 的权限信息虽然主要存在 mysql.user 表里，但直接用 mysqldump mysql user 导出再导入新实例，大概率失败。原因有三：user 表结构在不同版本间有差异（比如 5.7 和 8.0 的 authentication_string 字段替代了 password）；部分字段（如 plugin、account_locked）依赖服务端默认值或运行时状态；更重要的是，8.0+ 默认启用 caching_sha2_password 插件，而旧 dump 可能含过期的哈希格式，导入后用户无法登录。
用 SHOW GRANTS FOR 逐个生成可执行的授权语句
这是最兼容、最安全的迁移方式，适用于所有 MySQL 版本（5.6–8.4），且不依赖表结构一致性。核心思路是：对每个需要迁移的账号，调用 SHOW GRANTS FOR 'user'@'host'，把返回的 GRANT 语句保存下来，在新服务器上直接执行。
实操建议：
- 先查出所有非内置账号：
SELECT CONCAT('\'', user, '\'@\'', host, '\'') FROM mysql.user WHERE user NOT IN ('mysql.infoschema','mysql.session','mysql.sys','root'); - 对每个账号执行：
SHOW GRANTS FOR 'u1'@'192.168.%';，结果类似：GRANT SELECT ON `db1`.* TO 'u1'@'192.168.%'<br>GRANT INSERT, UPDATE ON `db2`.`t1` TO 'u1'@'192.168.%'
- 注意：如果账号有
WITH GRANT OPTION，必须确保目标服务器上该账号已存在（否则GRANT会报错），建议先用CREATE USER创建空账号，再授予权限 - 8.0+ 中若用户使用了角色（
ROLE），需额外导出SHOW GRANTS FOR ROLE 'role_name'和SELECT * FROM mysql.role_edges关系
mysqldump --all-databases 不等于权限全量迁移
很多人误以为全库 dump 包含权限，其实不然。默认情况下，mysqldump --all-databases 会跳过 mysql 库（除非显式加上 --databases mysql），即使加了，它也只导出表数据，不处理权限生效逻辑（例如 FLUSH PRIVILEGES 不会被自动触发）。更关键的是：dump 文件里的 INSERT INTO mysql.user 语句在 8.0+ 上基本不可执行——字段缺失、密码哈希不匹配、插件不兼容等问题会直接导致导入中断。
如果你坚持用 dump 方式，请严格按以下顺序操作：
- 在源库执行：
mysqldump --skip-triggers --compact --no-create-info --where="user NOT LIKE 'mysql.%'" mysql user db tables_priv columns_priv procs_priv proxies_priv > grants.sql - 手动编辑
grants.sql，删掉所有INSERT中的password字段（8.0+ 已废弃），替换authentication_string值为''或用SHA2('xxx',256)重算（不推荐） - 在新库先
CREATE USER，再导入语句，最后手动执行FLUSH PRIVILEGES
迁移后必须验证的三个点
权限迁移不是“执行完就完事”，漏掉验证容易线上翻车：
- 用目标账号连接新库，执行
SELECT USER(), CURRENT_USER();确认实际匹配的账号名和 host 是否符合预期（比如'u1'@'%'可能被'u1'@'localhost'优先匹配） - 检查具体权限是否生效：
SHOW GRANTS FOR 'u1'@'192.168.%';，比对与源库输出是否一致；特别注意库级、表级、列级权限是否完整 - 测试业务 SQL 是否能跑通，尤其是涉及
INSERT ... ON DUPLICATE KEY UPDATE、存储过程调用、视图查询等隐式依赖权限的操作
跨大版本迁移（如 5.7 → 8.0）时，CREATE USER 语法、默认认证插件、密码强度策略都可能变化，这些细节比权限语句本身更容易卡住上线。
