17370845950

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 文件放在无权限控制的共享目录里——这才是真正的单点失效口。