MySQL用户权限备份与恢复需操作mysql库中的权限表，可通过mysqldump备份整个mysql库或仅权限表，也可导出GRANT语句；恢复时导入对应SQL文件并执行FLUSH PRIVILEGES；注意版本兼容性、定期备份及测试恢复流程。
mydumper 本身不支持按「用户权限」维度拆分恢复 —— 它只备份数据表结构与内容，不导出 mysql 系统库中的权限表（如 user、db、tables_priv），除非你显式指定备份该库。
所以，所谓“权限维度的拆分恢复”，本质是两件事：单独备份权限 + 单独恢复权限，且必须绕过 mydumper 的默认行为。
mydumper 默认不备份权限表，为什么？
mydumper 默认跳过系统库（information_schema、performance_schema、sys、mysql），这是硬编码策略。即使你用 -B mysql，它也会静默忽略（v0.14.5 及之前版本确认如此）。
常见错误现象：
- 执行
mydumper -u u_mydumper -p ... -B mysql -o /tmp/mysql_bak后，目录为空或只有metadata文件； - 恢复后发现用户全没了，
SELECT user,host FROM mysql.user返回空。
如何单独备份 MySQL 权限信息？
用原生工具配合 mysqldump，而非 mydumper：
-
备份全部权限表（推荐）：
mysqldump -u root -p --single-transaction mysql user db tables_priv columns_priv procs_priv proxies_priv > mysql_privs.sql
-
或更稳妥地导出可执行的
GRANT语句（跨版本兼容性更好）：mysql -u root -p -N -e "SELECT CONCAT('SHOW GRANTS FOR ''',user,'''@''',host,''';') FROM mysql.user WHERE user != ''" | mysql -u root -p --skip-column-names | sed 's/$/;/g' > user_grants.sql
注意点：
- 必须用有
SUPER或BACKUP_ADMIN权限的账号执行； -
--single-transaction对mysql库无效（它是 MyISAM 表），但权限表写入极少，一致性风险低； - 不要漏掉
proxies_priv（MySQL 5.7+）和role_edges（8.0+ 角色相关）。
如何把权限恢复进目标实例？
直接导入即可，但有两个关键动作不能省：
-
导入 SQL 文件：
mysql -u root -p mysql < mysql_privs.sql
-
立即刷新权限缓存：
mysql -u root -p -e "FLUSH PRIVILEGES;"
容易踩的坑：
- 恢复时没指定
mysql库名（mysql -u ... < file.sql缺失库名会导致表被建到test或当前默认库）； - 导入后忘记
FLUSH PRIVILEGES，新权限不生效（MySQL 不自动重载权限表）； - 在 8.0+ 环境中，若用
mysqldump备份的权限表直接导入，可能因authentication_string字段长度或插件变更报错，此时必须用GRANT语句方式。
能否把权限恢复“嵌入”到 myloader 流程里？
不能。myloader 只读取 mydumper 生成的备份目录结构（<em>-schema.sql</em>、.sql、metadata），它不认识 mysql_privs.sql 这类外部文件，也不解析 GRANT 语句。
如果你希望自动化，需在 myloader 执行完毕后，额外加一步 shell 脚本调用 mysql 导入权限文件。
真正复杂的点在于：权限恢复不是“数据恢复”，而是“元数据治理”。它要求你清楚知道哪些用户该存在、哪些 host 限制要保留、是否启用了角色或密码历史策略——这些都无法靠工具自动推断，必须人工核对或从配置管理平台同步。
