正确导出mysql权限应使用mysqldump配合--single-transaction等参数导出mysql.user、db、tables_priv等全部权限相关表，而非直接select mysql.user；导入前需truncate权限表并按序执行，且须flush privileges生效。
直接导出 mysql.user 表会丢权限，别这么干
mysql 的用户与权限不是只存在 mysql.user 一张表里，硬 select 导出会漏掉数据库级（mysql.db）、表级（mysql.tables_priv）、列级、甚至存储过程权限。更关键的是：mysql.user 里的 authentication_string 字段是哈希值，但不同 mysql 版本用的哈希算法可能不同（比如 5.7 默认 mysql_native_password，8.0 默认 caching_sha2_password），直接 insert 到新实例很可能登录失败。
- 真正可靠的导出方式是用
mysqldump配合--skip-triggers --compact，只 dump 系统库的权限相关表 - 必须包含的表有：
mysql.user、mysql.db、mysql.tables_priv、mysql.columns_priv、mysql.procs_priv、mysql.proxies_priv（如果用了代理用户） - 跳过
mysql.plugin和mysql.servers，它们和权限无关，还容易因插件版本不兼容报错
mysqldump 备份权限表时必须加 --single-transaction 和 --skip-lock-tables
系统表在运行中可能被后台线程修改（比如刷新权限、创建用户），不加事务控制会导致导出数据状态不一致——例如 user 表里有用户，但 db 表里没对应记录，恢复后权限就残缺。而 --lock-tables 默认会锁所有表，对线上库基本不可行。
- 正确命令示例：
mysqldump -u root -p --single-transaction --skip-lock-tables --databases mysql --tables user db tables_priv columns_priv procs_priv proxies_priv > mysql_grants.sql
- MySQL 5.6 及以下不支持
--single-transaction对 MyISAM 表生效，此时必须停写或接受短暂不一致风险 - 导出文件里会有
CREATE DATABASE IF NOT EXISTS `mysql`;，恢复前得手动删掉这行，否则可能覆盖原mysql库结构
恢复到目标实例前，先清空旧权限表再导入
直接 mysql 会触发主键冲突或外键约束失败（尤其是 <code>mysql.user 里 root@localhost 已存在）。也不能用 DROP TABLE 全删——mysql 库结构由 MySQL 初始化脚本生成，删表可能破坏系统完整性。
- 安全做法是：用
TRUNCATE TABLE清空各权限表，再导入 SQL（注意顺序：先user，再db，最后其他） - 执行前确认目标实例 MySQL 版本 ≥ 源实例，否则高版本导出的字段（如 8.0 的
password_last_changed）在低版本会报错 - 导入后立刻运行
FLUSH PRIVILEGES;，否则内存中的权限缓存不会更新
迁移后测试 SHOW GRANTS 比查表更可靠
光看 SELECT * FROM mysql.user 不能验证权限是否生效——因为权限是多层叠加计算的（全局 + DB + 表 + 列），且 SHOW GRANTS FOR 'user'@'host' 才是 MySQL 实际校验时用的逻辑。另外，8.0 引入的角色（ROLE）权限不会出现在传统表中，得单独处理。
- 逐个用户执行：
SHOW GRANTS FOR 'app_user'@'10.%.%';，对比源库输出是否一致 - 如果用了角色，必须额外导出
mysql.role_edges和mysql.default_roles表，并确保目标实例已创建对应角色 - 特别注意
WITH GRANT OPTION权限——它不会体现在普通GRANTS输出里，得查mysql.user的Grant_priv字段是否为Y
权限迁移最麻烦的从来不是导出导入动作本身，而是隐式依赖：比如某个用户能访问某库，是因为他属于某个角色，而那个角色又依赖另一个角色……这种链式关系靠肉眼查表几乎不可能理清，必须用 SHOW GRANTS 一层层验。
