mysqldump执行用户最小权限为SELECT+SHOW VIEW+TRIGGER+LOCK TABLES；含--databases需额外SHOW DATABASES；备份存储过程还需EXECUTE；BACKUP_ADMIN对mysqldump无效。
mysqldump 执行用户必须拥有哪些最小权限
仅靠 SELECT 权限无法完成可靠备份。若需导出表结构（SHOW CREATE TABLE）、获取库列表（SHOW DATABASES）、锁定表（--single-transaction 或 --lock-tables），对应权限缺一不可。
最小可行权限组合取决于备份方式：
- 纯逻辑备份（
mysqldump --single-transaction）：需要SELECT+SHOW VIEW+TRIGGER+LOCK TABLES（除非加--skip-lock-tables） - 含
CREATE DATABASE语句的备份（--databases或--all-databases）：还需SHOW DATABASES - 备份存储过程/函数：额外需要
EXECUTE
不建议直接用 root 用户执行日常备份；应创建专用账号并显式授权，例如：
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'strong_pass'; GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO 'backup_user'@'localhost'; GRANT SHOW DATABASES ON *.* TO 'backup_user'@'localhost'; FLUSH PRIVILEGES;
恢复时 mysql 客户端连接用户权限不足的典型报错
恢复 SQL 文件时最常遇到的是 ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation。这通常不是因为没给 SUPER，而是备份中包含了 SET @@SESSION.SQL_LOG_BIN=0、CREATE DEFINER 或 EVENT 等需高权限的语句。
解决思路分两类：
通过 yarn-threads-cli 与 Threads（Meta）交互。当用户想要阅读首页动态、点赞、收藏的帖子或特定帖子时使用；查看...
- 重建备份：用
mysqldump --skip-definer --skip-log-bin --no-create-info等参数过滤掉敏感指令 - 临时提权恢复：在目标实例上为恢复用户授予
SUPER（MySQL 5.7）或SYSTEM_VARIABLES_ADMIN+BINLOG_ADMIN（MySQL 8.0+），恢复完立即撤销 - 改写 SQL：用
sed或脚本批量替换DEFINER=`user`@`host`为DEFINER=CURRENT_USER，避免硬编码权限依赖
备份文件本身的安全风险与防护措施
备份文件（如 dump.sql）本质是明文，包含完整表结构、数据甚至密码哈希（如 mysql.user 表）。一旦泄露，等同于数据库裸奔。
关键防护动作：
- 备份输出路径不能放在 Web 可访问目录（如
/var/www/html/backup/），应设为chmod 600并归属专用系统用户（如backup:backup） - 传输过程禁用
scp明文密码，改用密钥对；跨网络传输必须走gpg加密：mysqldump ... | gpg --encrypt --recipient 'backup-key' > backup.sql.gpg
- 避免在命令行中写密码：
mysqldump -u user -p'pass' db会暴露密码至ps aux和 shell 历史；应使用~/.my.cnf并设chmod 600
MySQL 8.0+ 中 BACKUP_ADMIN 权限的实际作用边界
BACKUP_ADMIN 是 MySQL 8.0 引入的专用权限，但它**只对原生企业版备份工具 mysqlbackup 有效，对 mysqldump 完全无效**。很多团队误以为授予该权限就能跑通所有备份脚本，结果仍卡在 SELECT 权限拒绝上。
真正影响 mysqldump 的仍是传统权限体系。若你用的是 Percona XtraBackup 或物理备份方案，BACKUP_ADMIN 才有意义——但它仍需配合 RELOAD、PROCESS、LOCK TABLES 等基础权限才能工作。
容易被忽略的一点：BACKUP_ADMIN 不隐含 SELECT，所以即使开了这个权限，也不能跳过对业务库的 SELECT 授权。
