只给备份所需的最小权限，别用 root
MySQL 备份（尤其是
mysqldump）不需要全库 DDL 或用户管理权限。用 root 做备份不仅违反最小权限原则，还放大了凭证泄露风险。实际只需
SELECT、
LOCK TABLES（单库逻辑备份时）、
SHOW VIEW（含视图的库）、
TRIGGER（含触发器的表）这四类权限。
SELECT是必须的，否则
mysqldump读不到数据
LOCK TABLES在非
--single-transaction模式下用于保证一致性；若用 InnoDB 且加了该参数，可省略此权限 如果备份库中存在视图，必须加
SHOW VIEW，否则
mysqldump报错
Access denied; you need (at least one of) the SHOW VIEW privilege(s)同理，有触发器的表需
TRIGGER权限，否则 dump 出的 SQL 会缺失
CREATE TRIGGER语句
创建专用备份用户的完整 SQL
执行以下语句创建用户并授予权限（以备份库
app_db为例）：
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'strong_password_123'; GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON `app_db`.* TO 'backup_user'@'localhost'; FLUSH PRIVILEGES;
注意：
`app_db`.*中的反引号不能省——若库名含短横线（如
my-app），不加引号会导致语法错误；
FLUSH PRIVILEGES必须执行，否则权限不生效。 不要授予
ALL PRIVILEGES或
RELOAD（影响
FLUSH LOGS等敏感操作） 主机限定为
'localhost'，避免网络暴露；如需远程备份，改用内网 IP + 防火墙白名单，而非
'%'密码必须强，且建议用 MySQL 8.0+ 的
caching_sha2_password插件（5.7 可用
mysql_native_password兼容旧客户端）
验证权限是否足够：用备份命令实测
直接运行一次
mysqldump并检查输出和退出码，比查
SHOW GRANTS更可靠：
mysqldump -u backup_user -p app_db --single-transaction --routines --events > /tmp/app_db.dump
常见失败信号：
报错Access denied for user 'backup_user'@'localhost' to database 'app_db'→ 用户没被授权该库 报错
Couldn't execute 'SHOW CREATE VIEW ...': Access denied→ 缺
SHOW VIEW报错
Access denied; you need the PROCESS privilege→ 错误启用了
--all-databases或未限定库名，导致尝试访问
information_schema等系统库
成功后检查 dump 文件头是否有
CREATE DATABASE和完整表结构，确认
--routines（存储过程）和
--events（事件）也正常导出。
备份脚本里别硬编码密码
在 shell 脚本或 cron 中直接写
-p'password'会导致密码出现在进程列表（
ps aux可见）和 shell 历史中。正确做法是使用 MySQL 配置文件：
[client] user = backup_user password = strong_password_123
存为
/etc/mysql/backup.cnf，权限设为
600（仅 root 可读），然后调用：
mysqldump --defaults-extra-file=/etc/mysql/backup.cnf app_db > backup.sql配置文件路径必须用绝对路径，相对路径在 cron 下会失效 文件权限漏设为
600是高频疏忽——MySQL 会拒绝读取权限过宽的配置文件，并报错
File '/path/to.cnf' not found or not readable不要用
~/.my.cnf，因为 cron 默认没有 HOME 环境变量，路径解析会失败
权限配置容易一劳永逸地忽略后续变更——比如新增视图或触发器后忘了补权限，备份就静默丢失关键对象。每次结构变更后，都该重跑一次验证命令。
