mysqldump默认不导出用户权限，因用户信息存于mysql系统库且被默认排除，即使--all-databases在8.0+也禁导敏感表；正确做法是显式导出mysql.user等表并注意跨版本密码字段与认证插件兼容性。
mysqldump 默认不导出用户权限，直接迁移数据库文件或执行 mysqldump 备份再导入后，新库中不会有原用户的账号、密码、权限配置——这是最常见的权限丢失根源。
为什么 mysqldump 不导出用户？
mysqldump 默认只操作业务数据库（如 myapp_db），而用户信息存在系统库 mysql 中，该库被默认排除。即使加 --all-databases，MySQL 8.0+ 也禁止导出 mysql 库的敏感表（如 user、global_grants），避免密码哈希泄露风险。
导出用户权限的正确命令组合
必须显式指定 mysql 库中的关键表，并跳过二进制日志写入（否则导入会失败）：
- 导出用户账号与认证信息：
mysqldump -u root -p --skip-triggers --compact --no-create-info --skip-extended-insert mysql user db global_grants role_edges default_roles > users.sql - 导出数据库级权限：
mysqldump -u root -p --skip-triggers --compact --no-create-info --skip-extended-insert mysql db > db_privs.sql - 导出表级权限（如需）：
mysqldump -u root -p --skip-triggers --compact --no-create-info --skip-extended-insert mysql tables_priv columns_priv procs_priv > tbl_privs.sql
注意：--skip-triggers 防止触发器干扰；--no-create-info 避免重复建表语句；--skip-extended-insert 让每行 INSERT 独立，便于排查某条权限插入失败。
导入时权限表主键冲突与密码兼容性问题
MySQL 5.7 和 8.0 的 user 表结构不同（如 plugin 字段值、authentication_string vs password），直接导入会导致：
- ERROR 1396 (HY000): Operation CREATE USER failed for 'xxx'@'%'
- ERROR 1062 (23000): Duplicate entry 'xxx-localhost' for key 'PRIMARY'
- 用户能登录但权限不生效（因
plugin值不匹配，如caching_sha2_password在旧客户端不可用）
解决办法：
- 在目标库先清空再导入：
TRUNCATE mysql.user; TRUNCATE mysql.db;（仅限测试/全新环境） - 生产环境应逐条重建用户：
CREATE USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; GRANT SELECT,INSERT ON mydb.* TO 'app_user'@'%'; - 若目标为 MySQL 8.0+ 且需兼容老应用，创建用户时显式指定
IDENTIFIED WITH mysql_native_password
更安全的替代方案：用 SELECT INTO OUTFILE + LOAD DATA
绕过 mysqldump 对系统表的限制，直接从 mysql.user 提取可读字段：
SELECT User,Host,authentication_string,plugin FROM mysql.user INTO OUTFILE '/tmp/users.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';
再在目标库用 LOAD DATA INFILE 导入并重建用户（需提前处理密码哈希兼容性）。这种方式可控性强，但要求源库 secure_file_priv 允许写入，且不能直接还原权限逻辑，仍需人工映射 GRANT 语句。
实际迁移中，用户权限往往比业务数据更难对齐——因为涉及认证插件、密码策略、角色继承等隐式依赖，建议始终以“最小权限重建”代替“全量复制”，尤其在跨版本迁移时。
