BACKUP_ADMIN需配合RELOAD、LOCK TABLES、REPLICATION CLIENT、PROCESS、SELECT及mysql.backup_*表特定权限才能完成备份，单独授予无效。
BACKUP_ADMIN 是 MySQL 8.0 中替代旧版 SUPER 权限中备份相关能力的核心动态权限，不能单独授予，必须配合 LOCK TABLES、RELOAD 等权限才能完成实际备份操作。
BACKUP_ADMIN 单独授予为什么不起作用
只执行 GRANT BACKUP_ADMIN ON *.* TO 'backupuser'@'%' 后，用 mysqlbackup 或执行 FLUSH TABLES WITH READ LOCK 仍会报错（如 ERROR 1227），因为 BACKUP_ADMIN 本身不包含锁表、刷新日志等能力。它仅控制「是否允许发起备份流程」这一入口权限，底层动作依赖其他权限协同：
-
LOCK TABLES：用于获取一致性的表级锁（mysqldump --single-transaction在 InnoDB 下可绕过，但mysqlbackup和物理备份仍需） -
RELOAD：用于执行FLUSH LOGS、FLUSH TABLES等关键刷新操作 -
PROCESS：部分备份工具需读取线程状态判断事务活跃度 -
REPLICATION CLIENT：记录 binlog 位置，支撑增量恢复
配置 mysqlbackup 用户所需的最小权限组合
以官方推荐的 mysqlbackup 工具为例（非 mysqldump），必须组合授予以下权限，缺一不可：
-
BACKUP_ADMIN（必需，入口权限） -
RELOAD（必需，触发FLUSH TABLES WITH READ LOCK） -
LOCK TABLES（必需，配合 RELOAD 完成一致性锁定） -
REPLICATION CLIENT（必需，获取 binlog 文件名和偏移量） -
PROCESS（必需，监控长事务、避免锁等待超时） -
SELECT（必需，读取所有库表数据） -
CREATE、INSERT、DROP、UPDATEonmysql.backup_progressandmysql.backup_history（必需，记录备份过程与元数据） -
SELECT、ALTERonmysql.backup_history（必需，查询/清理历史记录）
示例语句（注意：MySQL 8.0 必须先 CREATE USER）：
CREATE USER 'mysqlbackup'@'localhost' IDENTIFIED BY 'strong_password'; GRANT BACKUP_ADMIN, RELOAD, LOCK TABLES, REPLICATION CLIENT, PROCESS, SELECT ON *.* TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, UPDATE ON mysql.backup_progress TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, UPDATE, SELECT, ALTER ON mysql.backup_history TO 'mysqlbackup'@'localhost';
常见误配与兼容性陷阱
容易忽略的细节会导致备份失败，且错误提示不直观：
- 在 MySQL 8.0.14 之前版本，
BACKUP_ADMIN尚未引入，此时必须用SUPER—— 但该权限已在 8.0.16+ 被标记为废弃，GRANT SUPER会触发 warning 并可能被拒绝 - 忘记给
mysql.backup_history表授ALTER权限 → 备份成功但后续mysqlbackup --list-image报 ERROR 1142（权限不足） - 用
GRANT ALL PRIVILEGES替代精细授权 → 可能隐式包含已移除权限（如FILE），触发启动警告，且违反最小权限原则 - 用户 host 写成
'%'但客户端连接使用127.0.0.1→ 实际匹配的是'mysqlbackup'@'127.0.0.1'，权限不生效（建议显式创建两个 host）
BACKUP_ADMIN 不是“开了就能备份”的开关，它是一组权限协作中的关键一环；漏掉任何一个依赖权限，都会在某个具体步骤卡住，而错误信息往往指向更底层的操作（比如 LOCK TABLES 失败），而不是权限本身。
