backup_admin是mysql 8.0引入的专用动态权限，用于执行lock instance for backup等备份核心操作，不控制数据读写；grant select on .无法替代，因其仅提供数据查询能力，与备份锁、日志状态访问等完全无关。
BACKUP_ADMIN 是什么，为什么不能用 GRANT SELECT ON *.* 代替
BACKUP_ADMIN 是 MySQL 8.0 引入的专用动态权限，用于替代旧版 SUPER 权限中与备份强相关的部分（如 LOCK INSTANCE FOR BACKUP、LOCK BINLOG FOR BACKUP）。它不控制数据读写，只允许执行备份锁、查询 performance_schema.log_status 等关键操作。直接给 SELECT ON *.* 或 SUPER 属于越权——前者没用，后者过度开放。
授予 BACKUP_ADMIN 的正确语法和常见错误
必须用标准 GRANT 语句，对象范围固定为 *.*，不能指定库或表：
GRANT BACKUP_ADMIN ON *.* TO 'backup_user'@'10.0.1.%';
- 错误写法：
GRANT BACKUP_ADMIN ON mydb.* TO ...→ 报错 ERROR 3724（权限对象不合法） - 错误写法：
GRANT BACKUP_ADMIN ON *.* TO 'backup_user'@'%'但 host 写成'%'而非具体网段 → 可能被防火墙或安全策略拦截，建议限定 IP 段 - 必须搭配
FLUSH PRIVILEGES才生效（MySQL 8.0+ 动态权限仍需刷新元数据缓存）
撤销 BACKUP_ADMIN 必须用 REVOKE SYSTEM PRIVILEGE
BACKUP_ADMIN 是动态权限，不能用老式 REVOKE BACKUP_ADMIN ON *.* FROM ...，否则报错 ERROR 3724：
REVOKE SYSTEM PRIVILEGE BACKUP_ADMIN ON *.* FROM 'backup_user'@'10.0.1.%';
- 撤销后已建立的连接仍保留该权限，必须重连才失效
- 不能与其他动态权限合并撤销，比如
REVOKE SYSTEM PRIVILEGE BACKUP_ADMIN, LOCK_TABLES ON *.*→ 语法错误 - 验证是否撤干净：执行
SHOW GRANTS FOR 'backup_user'@'10.0.1.%'，输出里不应再出现BACKUP_ADMIN行
BACKUP_ADMIN 单独不够，必须搭配其他权限才能完成完整备份
仅授 BACKUP_ADMIN 会导致 XtraBackup 或 mysqlbackup 报错，例如 “Access denied; you need LOCK TABLES” 或 “Cannot read log_status”。实际最小权限组合至少包括：
-
BACKUP_ADMIN（必需） -
RELOAD（用于FLUSH TABLES WITH READ LOCK） -
LOCK TABLES（配合RELOAD实现一致性快照） -
REPLICATION CLIENT（读取 binlog 位点） -
PROCESS（监控线程状态） -
SELECT ON performance_schema.log_status（XtraBackup 8.0+ 显式需要）
漏掉 SELECT ON performance_schema.log_status 是最容易被忽略的一点——它不包含在任何全局权限里，必须单独授予。
