仅授予 RELOAD 和 LOCK TABLES 不足以完成完整备份，因 mysqldump 还需 SELECT 权限读取数据、SHOW VIEW 权限导出视图定义，否则会报 Access denied 错误。
为什么只给 RELOAD 和 LOCK TABLES 不够做完整备份
单纯授予 RELOAD 和 LOCK TABLES 权限，只能支持 mysqldump --single-transaction（InnoDB）或 --lock-all-tables 场景下的部分操作，但实际会卡在权限校验上——mysqldump 在导出前默认尝试 FLUSH TABLES WITH READ LOCK，这需要 RELOAD；而加全局读锁还隐式依赖 LOCK TABLES。但问题在于：如果用户没有对应数据库的 SELECT 权限，mysqldump 会直接报错 Access denied; you need (at least one of) the SELECT privilege(s) for this operation。
-
RELOAD仅允许执行FLUSH类命令，不赋予读数据能力 -
LOCK TABLES允许显式加表级锁，但无法绕过对象访问权限检查 - 多数备份工具（包括
mysqldump、mydumper）必须能SELECT才能读取表内容
真正可运行备份的最小权限组合
以对数据库 app_db 做逻辑备份为例，需同时授予三类权限：
-
SELECT：读取所有表数据（必需） -
SHOW VIEW：导出视图定义（否则mysqldump报错Access denied for view xxx） -
LOCK TABLES+RELOAD：支持--single-transaction失败时的降级锁表策略（如含 MyISAM 表）
执行语句如下（注意替换用户名和主机）：
GRANT SELECT, SHOW VIEW, LOCK TABLES, RELOAD ON `app_db`.* TO 'backup_user'@'192.168.1.%';
如果要备份多个库，需为每个库单独授权；不能用 ON *.*，否则过度提权。
使用 mysqldump 时的关键参数匹配权限
权限配好了，命令也得对得上，否则仍会失败：
- 用
--single-transaction（推荐，InnoDB 默认一致性快照）→ 只依赖SELECT，RELOAD和LOCK TABLES实际不触发，但建议保留以防万一 - 用
--lock-all-tables→ 必须有RELOAD（触发FLUSH TABLES WITH READ LOCK）和LOCK TABLES - 用
--master-data=2→ 额外需要REPLICATION CLIENT权限，否则报错Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s)
安全起见，日常备份建议组合：mysqldump -ubackup_user -p --single-transaction --routines --triggers app_db，此时只需 SELECT + SHOW VIEW 即可，RELOAD/LOCK TABLES 是兜底项。
容易被忽略的权限陷阱
生产环境最容易栽在这些细节上：
- 用户 host 匹配失败：比如授了
'backup_user'@'localhost'，但备份脚本从远程连，得用'backup_user'@'%'或具体 IP 段 - 未刷新权限：执行
GRANT后忘记FLUSH PRIVILEGES;（MySQL 8.0+ 通常自动刷新，但低版本或特殊部署仍需手动） - 存储过程/函数导出失败：若库中有
DEFINER非当前用户的 routine，还需EXECUTE权限或改用--skip-definer - 系统库误授权：切勿对
mysql库赋权，backup_user只应有业务库权限
最稳妥的做法是先用最小集（SELECT+SHOW VIEW）测试 mysqldump --single-transaction 能否成功，再根据错误信息逐条追加缺失权限，而不是一上来就堆一堆权限。
