backup_admin是mysql 8.0系统级动态权限，必须用grant backup_admin on .授予，限定库表会报error 3724；单独授予无效，需搭配reload、lock tables、replication client、process及select on performance_schema.log_status，且撤销须用revoke system privilege语法并重连生效。
BACKUP_ADMIN 不能用 GRANT SELECT ON *.* 替代，也不能绑定到具体库或表——它必须作用于 *.*，且单独授予毫无意义。
为什么 GRANT BACKUP_ADMIN ON mydb.* 会报错
MySQL 8.0 将 BACKUP_ADMIN 定义为系统级动态权限，只允许作用于全局范围 *.*。任何试图限定到数据库、表或列的写法都会触发 ERROR 3724 (HY000): Operation not allowed for this privilege)。
- 错误示例：
GRANT BACKUP_ADMIN ON mydb.* TO 'backup'@'10.0.1.%' - 正确写法：
GRANT BACKUP_ADMIN ON *.* TO 'backup'@'10.0.1.%' - host 部分建议用具体网段（如
'10.0.1.%'），避免用'%'增加攻击面 - 授完必须执行
FLUSH PRIVILEGES，否则权限不生效（即使 MySQL 8.0 大部分动态权限支持即时加载，BACKUP_ADMIN仍依赖元数据刷新）
只给 BACKUP_ADMIN 会导致备份工具失败
XtraBackup 或 mysqlbackup 启动时会检查多个权限点，仅 BACKUP_ADMIN 会让它们卡在第一步：要么提示 "Access denied; you need LOCK TABLES"，要么报 "Cannot read log_status"。
- 必需搭配：
RELOAD（用于FLUSH TABLES WITH READ LOCK）、LOCK TABLES（配合RELOAD实现一致性快照） - 必需搭配：
REPLICATION CLIENT（读取 binlog 位点）、PROCESS（监控线程状态） - 极易遗漏：
SELECT ON performance_schema.log_status—— 这个权限不继承自任何全局权限，必须显式授予：GRANT SELECT ON performance_schema.log_status TO 'backup'@'10.0.1.%'
撤销 BACKUP_ADMIN 的语法和陷阱
它不是普通权限，不能用老式 REVOKE ... ON *.* 语法。MySQL 会直接报 ERROR 3724。
- 正确撤销方式：
REVOKE SYSTEM PRIVILEGE BACKUP_ADMIN FROM 'backup'@'10.0.1.%' - 撤销后已存在的连接仍保有该权限，用户必须重连才能失效
- 不能合并撤销多个动态权限：
REVOKE SYSTEM PRIVILEGE BACKUP_ADMIN, CONNECTION_ADMIN FROM ...是非法语法 - 验证是否撤干净：
SHOW GRANTS FOR 'backup'@'10.0.1.%'输出中不应再出现BACKUP_ADMIN行
BACKUP_ADMIN 和 LOCK INSTANCE FOR BACKUP 的关系
LOCK INSTANCE FOR BACKUP 是 MySQL 8.0 引入的轻量级备份锁，替代了传统 FLUSH TABLES WITH READ LOCK。但它的执行前提是：当前用户拥有 BACKUP_ADMIN，且未被其他长事务阻塞。
- 这个语句本身不阻塞 DML，只阻塞 DDL 和某些日志操作，比 FTWRL 更友好
- 但它不提供数据读取能力——所以备份工具仍需
SELECT权限访问表数据 - 如果备份过程中遇到
ERROR 1290 (HY000): The MySQL server is running with the --read-only option，说明实例处于只读模式，LOCK INSTANCE FOR BACKUP会被拒绝，此时需先检查read_only状态
最常被忽略的是 performance_schema.log_status 的单独授权，以及撤销后不重连导致权限“看似已撤实则仍在”的问题——这两点在线上备份失败排查中占了七成以上案例。
