mysqldump可靠备份需SELECT、SHOW VIEW、TRIGGER、LOCK TABLES、SHOW DATABASES、EXECUTE六项最小权限；ERROR 1227主因是备份文件含DEFINER或SQL_LOG_BIN语句，应通过--skip-definer等参数重建备份或清洗脚本。
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 文件放在无权限控制的共享目录里——这才是真正的单点失效口。
