MySQL数据库备份恢复后，所有用户和权限都消失了？这确实是数据库迁移或灾难恢复中一个常见且令人困扰的“经典”问题。其根本原因非常明确，但备份与恢复过程中的关键细节却常常被忽视。
简单来说，权限丢失的根本原因，几乎可以确定是备份时遗漏了 mysql 系统数据库。所有用户账户、密码哈希值、以及关键的权限字段（如 Select_priv、Grant_priv），甚至角色关系，都存储在这个核心系统库中。如果只恢复了业务数据库，那么新实例上自然只剩下初始化时默认的 root@localhost 账户，其他所有用户和权限设置都将不复存在。
为什么只恢复业务数据库会导致权限全部丢失
这其实是一个默认备份行为的“陷阱”。使用 mysqldump 工具时，它默认不会导出系统库。即便你使用了 --databases db1 db2 这样的参数，mysql 库依然会被排除在外。于是，恢复后就会出现一系列典型症状：
- 尝试授权或查看权限时，报错
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备份恢复权限丢失问题，必须在备份时显式包含 mysql 系统库，同时注意生产环境下的锁表策略：
- 推荐方案（MySQL 5.7及以上）：使用
--single-transaction参数确保一致性快照，避免锁表。mysqldump -u root -p --single-transaction --routines --triggers --events mysql > mysql_system.sql - 兼容方案（旧版本或含MyISAM表）：可以关闭表锁以避免长时间阻塞。
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 < mysql_system.sql 很可能会失败，因为备份文件中通常包含 CREATE DATABASE mysql 和 USE mysql 语句，而 mysql 作为系统库是不允许被直接创建或删除的。
一个相对稳妥的导入流程如下：
- 停止MySQL服务：
sudo systemctl stop mysql。这一步是为了避免并发写入导致数据损坏。 - 以特殊模式启动：临时启动一个跳过权限检查的MySQL进程，
mysqld --skip-grant-tables --skip-networking &。注意，这仅用于紧急修复，且务必加上--skip-networking防止远程连接。 - 无密码登录：在新的会话中，使用
mysql -u root直接登录。 - 执行导入：在MySQL客户端内执行
source /path/to/mysql_system.sql;。这里的关键是使用source命令，而不是在shell中用重定向。 - 刷新权限：导入完成后，必须立即执行
FLUSH PRIVILEGES;，否则新的权限信息不会被加载。 - 恢复正常模式：退出客户端，结束刚才启动的
mysqld进程，然后以正常方式重启MySQL服务。
还有一个版本兼容性问题需要警惕：如果备份来自MySQL 5.7，而要恢复到8.0，不要强行导入。因为两个大版本间，mysql 系统库的表结构（例如 mysql.role_edges）可能已经改变。正确的做法是遵循官方的升级路径，或者使用下文提到的 pt-show-grants 工具来生成可移植的授权语句。
没有备份时的补救措施：用 pt-show-grants 重建授权
如果最坏的情况发生了：mysql 库已经丢失，且没有任何备份，又无法回退。这时，pt-show-grants（Percona Toolkit中的工具）就成了重建权限的“救命稻草”。它比手动编写 GRANT 语句要可靠和高效得多。
- 从源库（如果还能访问）生成授权文件：
pt-show-grants --user=root --password=xxx --host=old-host > grants.sql
这个工具会自动处理好CREATE USER、IDENTIFIED WITH认证插件、REQUIRE子句等所有细节。 - 在目标库导入：
mysql -u root -p < grants.sql
执行前，需确保执行导入操作的用户（如root）拥有CREATE USER权限。 - 特别注意MySQL 8.0的认证插件：默认的
caching_sha2_password插件可能不被一些老版本的客户端或驱动支持。如果遇到连接问题，在生成或创建用户时，可能需要指定IDENTIFIED WITH mysql_native_password。
最后，一个极易被忽略的细节是 host 字段的精确匹配。在MySQL的权限体系里，'app'@'%' 和 'app'@'localhost' 被视为两个完全独立的账户。通过Unix socket连接通常只识别后者，而TCP连接则使用前者。因此，在权限迁移完成后，务必验证应用程序的实际连接方式是否与 mysql.user 表中的权限记录精确对应，避免因主机名不匹配而导致连接失败。
