MySQL 中哪些权限控制备份与恢复操作
MySQL 本身不提供独立的
BACKUP或
RESTORE权限，备份与恢复行为是否被允许，取决于具体使用的工具和操作方式。核心判断依据是：用户能否读取数据（影响逻辑备份）、能否写入文件（影响
SELECT ... INTO OUTFILE类导出）、能否执行管理命令（影响物理备份或服务级操作）。
mysqldump 和 SELECT INTO OUTFILE 需要哪些权限
这类逻辑备份依赖用户的数据访问能力和文件导出能力。常见错误是只赋了
SELECT却无法导出文件，或漏掉
LOCK TABLES导致一致性问题。
SELECT：必须，用于读取表内容
LOCK TABLES：推荐，确保
mysqldump --single-transaction外的场景下一致性（尤其 MyISAM）
RELOAD：仅当使用
--master-data或需要
FLUSH TABLES WITH READ LOCK时才需要
FILE：仅当使用
SELECT ... INTO OUTFILE或
mysqldump --tab时需要；该权限控制服务器向磁盘写文件，**极其敏感，不应轻易授予**
示例最小化授权（仅支持常规
mysqldump，不含
--tab）：
GRANT SELECT, LOCK TABLES ON `mydb`.* TO 'backup_user'@'%';
mysqlpump 和 mysqlbinlog 恢复场景的权限差异
mysqlpump权限模型与
mysqldump基本一致，但若启用并行导出（
--default-parallelism），会额外需要
PROCESS权限来查询线程状态。
mysqlbinlog本身不走 MySQL 权限系统（它是客户端工具，直接读取二进制日志文件），但恢复时执行 SQL 语句仍受目标用户的权限约束。关键点在于： 如果用
mysqlbinlog | mysql -u user恢复，
user必须有对应表的
INSERT/UPDATE/CREATE等 DML/DDL 权限 若需通过
SET GLOBAL sql_log_bin = 0跳过记录日志，还需
SUPER（MySQL 5.7）或
SYSTEM_VARIABLES_ADMIN+
SESSION_VARIABLES_ADMIN（MySQL 8.0+）
MySQL 8.0+ 中禁用
SUPER后，恢复操作更依赖细粒度权限组合，容易因缺失
PERSIST_ROLES_ADMIN或
BACKUP_ADMIN报错——但注意：
BACKUP_ADMIN**仅控制企业版热备份插件（如 MySQL Enterprise Backup），对 mysqldump / mysqlbinlog 无影响**。
物理备份（如拷贝 ibd 文件）无法靠权限限制
MySQL 的文件级物理备份（如直接复制
datadir下的
.ibd或
.frm）完全绕过权限系统，由操作系统层面控制。这意味着： 即使用户在 MySQL 内没有任何权限，只要其 OS 账户能读取
/var/lib/mysql/，就能拷走数据文件 真正限制物理备份，必须靠文件系统权限（
chown/
chmod）、SELinux/AppArmor 策略，或使用专用备份账户隔离 OS 权限
BACKUP_ADMIN权限对物理文件拷贝不起作用，它只用于调用企业版备份 API
所以，单纯在 MySQL 内 GRANT/REVOKE 权限，对 rsync/cp 类备份毫无约束力。最容易被忽略的，就是把数据库权限和操作系统权限混为一谈。
