mysqldump 备份所需最小权限组合
仅靠
SELECT权限无法完成可靠备份——这是最常被低估的坑。实际执行
mysqldump时，不同参数会触发不同元数据查询和锁操作，缺一不可：
SELECT：读取表数据（必需）
SHOW VIEW：导出视图定义（否则视图变空或报错）
TRIGGER：导出触发器（否则
--triggers失效）
LOCK TABLES：配合
--lock-tables或隐式锁定（
--single-transaction在混合引擎下会退化为该行为）
SHOW DATABASES：使用
--databases或
--all-databases时必需（否则报
ERROR 1227或跳过库）
EXECUTE：导出存储过程/函数（
--routines开启时必需）
注意：
REPLICATION CLIENT和
PROCESS是旧文档中常见但冗余的推荐项；MySQL 5.7+ 的
mysqldump --single-transaction并不依赖它们；而
BACKUP_ADMIN对
mysqldump完全无效。
恢复 SQL 文件时报 ERROR 1227 的真实原因与解法
这个错误常被误认为“没给 SUPER 权限”，其实绝大多数情况是备份文件里带了高权限语句，而非用户真缺
SUPER：
SET @@SESSION.SQL_LOG_BIN = 0（
--skip-log-bin未启用时自动写入）
CREATE DEFINER=`xxx`@`%` PROCEDURE ...（
--skip-definer可禁用）
CREATE EVENT或含
DEFINER的视图/函数（需
EVENT+
EXECUTE权限）
实操建议分三类应对：
重建备份：加--skip-definer --skip-log-bin --no-create-info等过滤敏感指令（适合新备份） 临时提权：MySQL 8.0+ 授予
SYSTEM_VARIABLES_ADMIN+
BINLOG_ADMIN，恢复完立即
REVOKE脚本清洗：用
sed -i 's/DEFINER=`[^`]*`@`[^`]*`/DEFINER=CURRENT_USER/g'替换硬编码 definer（快速救急）
专用备份账号创建与权限隔离实践
绝不要用
root执行日常备份——权限过大、审计难、一旦密钥泄露即全库沦陷。应创建最小权限专用账号：
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'strong_pass_2026'; GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO 'backup_user'@'localhost'; GRANT SHOW DATABASES ON *.* TO 'backup_user'@'localhost'; GRANT EXECUTE ON *.* TO 'backup_user'@'localhost'; -- 如需备份存储过程 FLUSH PRIVILEGES;
关键细节：
限定@'localhost'而非
@'%'，避免网络侧暴露 若只备份特定库，把
ON *.*改为
ON `db_name`.*（注意反引号） 不授予
UPDATE/
DELETE/
DROP等写权限——备份账号只需“看”和“锁”
备份文件本身是最大安全盲区
备份文件（如
dump.sql）是明文，包含完整结构、业务数据、甚至
mysql.user表里的密码哈希。一次泄露 ≈ 全库裸奔。 存储时必须加密：
gpg --cipher-algo AES256 -c backup_$(date +%F).sql传输时禁用明文协议：用
rsync --rsh="ssh -c aes256-gcm@openssh.com"禁止在备份命令行中写密码：
mysqldump -u backup_user -p db > f.sql（交互输），或用
~/.my.cnf配置并
chmod 600
最容易被忽略的一点：很多团队花大力气加固数据库访问权限，却把每天生成的
.sql文件放在无权限控制的共享目录里——这才是真正的单点失效口。
