MySQL备份只需SELECT和LOCK TABLES权限，必要时加REPLICATION CLIENT；应限定库级授权、严格主机限制，并避免过度权限如ALL PRIVILEGES或SHOW DATABASES。
只给备份账号 SELECT 和 LOCK TABLES 就够了
MySQL 备份（尤其是用 mysqldump）不需要管理员权限。给备份账号 ALL PRIVILEGES 是典型权限过度，既增加风险，又可能在开启 sql_mode=STRICT_TRANS_TABLES 等严格模式时意外失败。
核心权限只有两个：SELECT（读取数据）和 LOCK TABLES（保障一致性快照）。其他如 RELOAD、PROCESS、SUPER 全都不必要——除非你明确要用 --master-data 或 --single-transaction 配合 GTID，那才额外需要 REPLICATION CLIENT。
-
SELECT：必须，所有表都要可读 -
LOCK TABLES：必须，否则mysqldump在非事务引擎（如 MyISAM）下会报错Access denied; you need (at least one of) the LOCK TABLES privilege(s) for this operation -
REPLICATION CLIENT：仅当加--master-data或需获取 binlog 位置时才需要 - 不要给
SHOW DATABASES：如果只想备份特定库，就显式指定库名，避免账号看到全部库名（信息泄露）
GRANT 语句怎么写才安全
直接对具体数据库授予权限，别用 *。备份账号不该有跨库访问能力，也不该能“发现”未授权的库。
假设只备份 app_db 和 log_db：
GRANT SELECT, LOCK TABLES ON `app_db`.* TO 'backup_user'@'localhost'; GRANT SELECT, LOCK TABLES ON `log_db`.* TO 'backup_user'@'localhost'; GRANT REPLICATION CLIENT ON *.* TO 'backup_user'@'localhost'; -- 仅需时添加 FLUSH PRIVILEGES;
注意点：
- 数据库名用反引号
`app_db`包裹，防止库名含短横或数字开头时报语法错误 - 主机限定越严越好：
'backup_user'@'10.0.2.5'比'backup_user'@'%'安全得多 - 执行完必须
FLUSH PRIVILEGES，否则权限不生效（尤其在跳过 grant 表启动时更明显） - 别用
GRANT ... IDENTIFIED BY修改密码：MySQL 8.0+ 已弃用该语法，改用ALTER USER 'backup_user'@'localhost' IDENTIFIED BY 'xxx';
mysqldump 命令里哪些参数会悄悄绕过权限检查
有些 mysqldump 参数看似只是“增强功能”，实则暗中要求额外权限。没配好就会 dump 失败，但错误提示往往不直接说缺哪个权限。
-
--single-transaction：要求 InnoDB 表，且账号需有RELOAD权限（用于FLUSH TABLES WITH READ LOCK的替代路径）——其实它并不真需要锁表，但旧版mysqldump实现会尝试检查该权限 -
--master-data=2：必须有REPLICATION CLIENT，否则报错Access denied; you need (at least one of) the REPLICATION CLIENT privilege(s) -
--events或--routines：分别需要EVENT和EXECUTE权限，而这两个权限通常和备份无关，别开 -
--all-databases：隐含需要SHOW DATABASES，且会 dump 所有库——违背最小权限原则，禁用
推荐稳妥组合：mysqldump -u backup_user -p --databases app_db log_db --lock-tables
MySQL 8.0+ 的角色机制能简化配置吗
能，但别图省事直接赋内置角色。MySQL 8.0 的 backup_admin 角色看起来很合适，但它包含 SYSTEM_VARIABLES_ADMIN 和 PERSIST_RO_VARIABLES_ADMIN 等高危权限，远超备份所需。
更可控的做法是自建角色：
CREATE ROLE 'backup_role'; GRANT SELECT, LOCK TABLES ON `app_db`.* TO 'backup_role'; GRANT SELECT, LOCK TABLES ON `log_db`.* TO 'backup_role'; GRANT REPLICATION CLIENT ON *.* TO 'backup_role'; GRANT 'backup_role' TO 'backup_user'@'localhost';
这样后续增减备份库只需改角色权限，不用动用户本身。但要注意：
- 角色默认不激活，用户登录后需执行
SET ROLE 'backup_role';（或在创建用户时用DEFAULT ROLE绑定） - MySQL 5.7 不支持角色，硬切 8.0+ 前先确认运维链路兼容性（比如某些备份脚本里的
mysql客户端版本太老） - 角色不能跨实例复用，主从结构中每个实例仍需单独配置
权限这事，粒度细一点，后面审计和排查就越少意外。特别是当备份账号被多个脚本或不同人使用时，多一层限制，就少一分误操作的余地。
