mysql中数据库备份与恢复中的权限控制

来源：这里教程网时间：2026-02-28 20:41:48 作者：

mysqldump 备份时需要哪些最小权限

仅执行备份不需要

ROOT

权限，但必须明确授予对应数据库的读取权限。常见错误是只给了

SELECT

却漏掉

LOCK TABLES

或

SHOW VIEW

，导致备份中途失败。

实际所需权限取决于备份选项：

基础表数据备份（
mysqldump db_name
）：需
SELECT
+
LOCK TABLES
（若未加
--single-transaction
）含视图导出（
--routines
或
--triggers
）：额外需要
SHOW VIEW
和
TRIGGER
导出存储过程/函数（
--routines
）：还需
EXECUTE
权限（MySQL 8.0+ 要求更严格）使用
--single-transaction
（InnoDB 推荐）：可省去
LOCK TABLES
，但要求事务隔离级别支持且不能有长事务阻塞

推荐建专用备份账号并最小授权：

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'strong_pass';
GRANT SELECT, SHOW VIEW, LOCK TABLES, TRIGGER, EXECUTE ON `myapp_db`.* TO 'backup_user'@'localhost';

mysql 命令恢复时权限不足的典型报错

恢复不是“单纯写入”，而是一系列

CREATE

、

DROP

、

INSERT

操作，权限缺失会直接中断。最常遇到的错误是：

ERROR 1142 (42000): CREATE command denied to user
—— 缺少
CREATE
权限
ERROR 1044 (42000): Access denied for user ...@... to database
—— 用户对目标库无任何权限（包括
USAGE
）
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s)
—— 尝试恢复含
DEFINER
的视图或函数，但用户没有
SET_USER_ID
（MySQL 5.7+）或
SUPER
（旧版）

解决方法分两种场景：

恢复到已有空库：确保用户对目标库有
CREATE
、
INSERT
、
DROP
、
ALTER
、
INDEX
权限恢复含 DEFINER 的对象：要么用
--skip-definer
导出（备份时），要么在恢复前执行
SET SQL_LOG_BIN = 0;
并用高权限账号操作（不推荐线上直接用）

如何避免 DEFINER 权限问题导致恢复失败

MySQL 默认导出的视图、函数、事件里会带

DEFINER=`user`@`host`

，恢复时若该用户不存在或当前用户无

SET_USER_ID

权限，就会报错。这不是备份本身的问题，而是 MySQL 的安全机制。

实操建议优先采用无依赖方式：

备份时加参数：
mysqldump --skip-definer --routines --triggers mydb > backup.sql
或用
--set-gtid-purged=OFF
（GTID 环境下防止权限扩散） 如果必须保留 DEFINER（如审计要求），则恢复前先创建对应用户，并确保其存在且有最小必要权限，而不是依赖 root 账号硬扛

注意：

DEFINER

在恢复后仍生效，后续调用视图或函数时，是以定义者身份执行的——这点常被忽略，可能引发越权访问。

用 mysqlpump 替代 mysqldump 时的权限差异

mysqlpump

是 MySQL 5.7+ 引入的并行逻辑备份工具，权限模型更细粒度。它默认不导出

mysql

系统库（除非显式指定），但对用户权限处理更敏感：

要导出用户账户（
--users
），需要
SELECT
权限在
mysql.user
表上，且 MySQL 8.0+ 还需
SELECT
on
mysql.global_grants
导出角色（
--include-roles
）需
SELECT
on
mysql.role_edges
即使不导出权限，
mysqlpump
内部也会查询
information_schema
多张表，比
mysqldump
多依赖
SELECT
on
INFORMATION_SCHEMA.VIEWS
等

所以迁移脚本时别假设权限完全通用。一个能跑通