备份账号权限须严格限定库、表、主机三重边界，仅授select和lock tables（目标库内），replication client仅当需binlog位点时全局授予，禁用show databases、process及通配符主机。
备份账号权限必须精确到库、表、主机三重边界，不能靠“差不多够用”来凑——越界授权会直接暴露未预期的数据库结构或数据，且在严格 SQL mode 下可能让 mysqldump 意外失败。
只给具体数据库的 SELECT 和 LOCK TABLES 权限
绝大多数逻辑备份只需要读取和临时锁表能力，SELECT 和 LOCK TABLES 是底线。但必须限定在目标库上，不能用 ON *.*。
- 错误写法：
GRANT SELECT, LOCK TABLES ON *.* TO 'backup_user'@'localhost';—— 这会让账号能看到所有库名（触发SHOW DATABASES效果），还可能跨库访问视图或触发器 - 正确写法（单库）：
GRANT SELECT, LOCK TABLES ON `app_db`.* TO 'backup_user'@'localhost'; - 多库需逐条授权：
GRANT SELECT, LOCK TABLES ON `log_db`.* TO 'backup_user'@'localhost'; - 库名含短横或数字开头时，反引号
`不可省；否则语法报错
REPLICATION CLIENT 权限只在需要 binlog 位点时才加
--master-data 或 --dump-slave 参数依赖 REPLICATION CLIENT 获取当前 binlog 文件与位置，用于后续增量恢复。不加这个参数就完全不需要它。
- 必须用
ON *.*授权，因为该权限是全局级的：GRANT REPLICATION CLIENT ON *.* TO 'backup_user'@'localhost'; - 如果只是本地定时全量备份、不对接复制链路，这条 GRANT 就不该存在
- MySQL 8.0+ 中它不可被替代，
SUPER已废弃，别试图用旧权限凑数
避免 SHOW DATABASES 和 PROCESS 权限
SHOW DATABASES 会让备份账号枚举出所有库名，属于信息泄露；PROCESS 允许查看其他连接的 SQL，对备份毫无必要，反而增加敏感操作风险。
-
mysqldump --databases db1 db2显式指定库名时，完全不需要SHOW DATABASES -
--all-databases才强制要求该权限，但生产环境应禁用此参数 -
PROCESS仅在--flush-logs或调试长事务时用到，日常备份脚本里没理由启用 - 检查现有账号是否误授：
SHOW GRANTS FOR 'backup_user'@'localhost';，发现SHOW DATABASES或PROCESS立即REVOKE
主机限制必须精确到 IP 或 localhost
权限生效范围由 'backup_user'@'host' 的 host 部分决定，'%' 是最危险的通配符。
- 本地脚本备份：用
'backup_user'@'localhost'，禁止远程连接 - 专用备份服务器：明确写死 IP，如
'backup_user'@'10.0.3.42'，不要用'10.0.3.%'网段 - MySQL 8.0+ 默认禁用
skip-name-resolve，DNS 解析失败可能导致@'hostname'匹配失败，优先用 IP - 授权后务必执行
FLUSH PRIVILEGES;，尤其在跳过 grant 表启动后更关键
最容易被忽略的是：权限最小化不是一次性动作。当业务新增库、加了视图或存储过程时，备份账号权限不会自动同步——必须人工确认 SHOW VIEW、TRIGGER、EXECUTE 是否补上，否则 mysqldump 会静默跳过或报错中断。
