backup_admin必须用on .显式授予，不支持库级限定；常见错误包括误写为on app_db.*（报错3724）、与reload/lock tables混授导致后者未绑定库而静默失败，且仅授此权限不足以完成备份，须补全reload、lock tables、replication client及select on performance_schema.log_status。
BACKUP_ADMIN 必须用 ON *.* 显式授予，不能限定库名
MySQL 8.0 中 BACKUP_ADMIN 是动态权限，作用域固定为全局，不支持库级限定。哪怕你只备份 app_db，授权语句也必须写成：
GRANT BACKUP_ADMIN ON *.* TO 'bkp'@'10.0.1.%';
常见错误包括：
-
GRANT BACKUP_ADMIN ON `app_db`.* TO ...→ 报错ERROR 3724 (HY000)，权限对象不合法 -
GRANT BACKUP_ADMIN ON *.* TO 'bkp'@'%'→ 虽语法正确，但若安全策略禁止通配 host，连接会静默拒绝；建议用具体网段 - 漏掉
FLUSH PRIVILEGES→ 动态权限需刷新元数据缓存才生效
不能和 RELOAD、LOCK TABLES 合并在同一条 GRANT 里
MySQL 8.0 权限模型严格区分作用域：BACKUP_ADMIN、REPLICATION CLIENT、PROCESS 是全局权限（ON *.*），而 RELOAD 和 LOCK TABLES 是库级权限，必须指定目标库。
错误写法（RELOAD 和 LOCK TABLES 实际未绑定任何库）：
GRANT RELOAD, LOCK TABLES, BACKUP_ADMIN ON *.* TO 'bkp'@'localhost';
正确做法是分两条：
GRANT RELOAD, LOCK TABLES ON `app_db`.* TO 'bkp'@'localhost';<br>GRANT BACKUP_ADMIN, REPLICATION CLIENT, PROCESS ON *.* TO 'bkp'@'localhost';
否则 xtrabackup 在 fallback 到 FLUSH TABLES WITH READ LOCK 时会静默失败，日志只显示 “Waiting for backup lock” 卡住。
仅授 BACKUP_ADMIN 不足以完成备份，必须补全最小权限集
BACKUP_ADMIN 单独存在时，xtrabackup 会报类似 Access denied; you need LOCK TABLES 或 Cannot read log_status 的错误。完整最小权限组合应包含：
-
BACKUP_ADMIN ON *.*（必需，启用备份锁） -
RELOAD, LOCK TABLES ON `target_db`.*（必需，配合实现一致性快照） -
REPLICATION CLIENT ON *.*（必需，读取 binlog 位点） -
SELECT ON performance_schema.log_status（极易遗漏！xtrabackup 8.0+ 显式依赖）
注意：SELECT ON performance_schema.log_status 不属于任何全局权限，必须单独授予，且不能用反引号包裹表名（即不能写成 `performance_schema`.`log_status`）。
验证权限是否真正生效，不能只看 SHOW GRANTS
SHOW GRANTS FOR 'bkp'@'localhost' 只能确认语句执行成功，无法反映实际行为。真正有效的验证方式是实操测试：
- 运行
xtrabackup --backup --target-dir=/tmp/test --user=bkp --password=xxx - 观察日志中是否出现
Using backup lock→ 表明BACKUP_ADMIN生效 - 若出现
FTWRL或卡在Waiting for backup lock→ 权限缺失或错配 - 若报
Access denied for SELECT on performance_schema.log_status→ 漏授该权限
权限校验的关键在于“行为反馈”，而不是语法通过。很多问题直到执行备份才发现，因为 MySQL 不会在授权阶段校验组合合理性。
