备份恢复后权限丢失，根本原因是未导出或未导入mysql系统库；用户、密码哈希及所有权限字段均存储于mysql库中，仅恢复业务库无效。
备份恢复后权限丢失，基本等于没导出或没导入 mysql 库——因为所有用户、密码哈希、权限字段（Select_priv、Grant_priv 等）、角色关系都存在里面，光恢复业务库毫无意义。
为什么只恢复业务库会导致权限全丢
mysqldump 默认不导出系统库；哪怕用了 --databases db1 db2，也不会碰 mysql。结果就是新实例只有初始化时的默认 root@localhost，其他用户全消失。常见现象包括：
- 登录报
ERROR 1141 (42000): There is no such grant defined for user -
SELECT user, host FROM mysql.user;返回空或只有本地 root - 旧应用连不上，提示
Access denied for user 'app'@'10.0.1.%'，但该用户在旧库明明存在
根本原因不是“权限没生效”，而是用户记录压根不存在。
正确导出 mysql 库的 mysqldump 命令
必须显式包含 mysql 库，且避开锁表冲突（尤其生产环境）：
- 用
--single-transaction保证一致性（5.7+）：mysqldump -u root -p --single-transaction --routines --triggers --events mysql > mysql_system.sql - 若版本较老或含 MyISAM 表，改用
--lock-tables=false：mysqldump -u root -p --lock-tables=false --routines --triggers mysql > mysql_system.sql - 绝对不要用
--all-databases直接导出——它会混入information_schema和performance_schema，导入时报错
导出前确认旧库中用户完整：SELECT user, host FROM mysql.user WHERE user != '';
导入 mysql_system.sql 的关键细节
直接 mysql -u root -p mysql 会失败，因为备份里含 <code>CREATE DATABASE mysql 和 USE mysql，而 mysql 是系统库，不能被 DROP 或 CREATE。
- 先停掉 MySQL：
sudo systemctl stop mysql（避免并发写入损坏） - 启动 mysqld 并跳过权限检查（仅限紧急修复）：
mysqld --skip-grant-tables --skip-networking & - 用 root 无密码登录：
mysql -u root - 执行：
source /path/to/mysql_system.sql;（注意：是source，不是 shell 重定向） - 必须立刻执行：
FLUSH PRIVILEGES;，否则权限不加载 - 退出，杀掉 mysqld 进程，再用正常模式重启服务
如果备份来自不同大版本（如 5.7 → 8.0），别硬导——mysql.role_edges 等表结构已变，应走官方升级路径，或用 pt-show-grants 生成可移植的 GRANT 语句。
没备份时的补救：用 pt-show-grants 重建授权
当 mysql 库已丢失且无 dump，又无法回滚，pt-show-grants 是最稳的替代方案（比手写 GRANT 更可靠）：
- 在旧库运行：
pt-show-grants --user=root --password=xxx --host=old-host > grants.sql - 该工具自动处理
CREATE USER、IDENTIFIED WITH插件、REQUIRE子句等细节 - 在新库导入：
mysql -u root -p （需确保目标库已存在，且用户有 <code>CREATE USER权限） - 特别注意 MySQL 8.0+ 的认证插件：
caching_sha2_password不被老客户端支持，建用户时得加IDENTIFIED WITH mysql_native_password
真正容易被忽略的点是 host 字段匹配——'app'@'%' 和 'app'@'localhost' 是两个完全独立的账户，socket 连接只认后者，TCP 才走前者。迁移后务必验证连接方式与权限记录是否对应。
