恢复数据时 mysqldump
导出文件能否导入，取决于目标库的权限组合
单纯有
SELECT权限不够，
INSERT、
CREATE、
DROP、
ALTER这几类权限缺一不可，具体看 SQL 文件内容。比如含
DROP TABLE语句就必须有
DROP；建新表要
CREATE；加索引或改字段需
ALTER；写入数据当然要
INSERT。
常见错误现象：
ERROR 1142 (42000): INSERT command denied to user 'xxx'@'%' for table 't1'或
ERROR 1044 (42000): Access denied for user 'xxx'@'%' to database 'db1'，基本都是权限缺失导致的。 若 SQL 文件来自
mysqldump --no-create-info，只需
INSERT（和
LOCK TABLES，如果用了
--lock-tables） 若含
CREATE DATABASE语句，用户还需
CREATE数据库权限（即
CREATEon
*.*） 使用
mysql --force不会绕过权限检查，只会跳过单条语句报错继续执行
GRANT
语句中哪些权限项对应恢复操作
运维中常误以为给
ALL PRIVILEGES最省事，但生产环境应最小化授权。以下是按恢复场景拆解的关键权限：
SELECT：仅用于
mysqldump导出，恢复时不强制需要
INSERT、
UPDATE、
DELETE：写入/修正数据必需
CREATE、
DROP、
ALTER：重建表结构必需（不含
--no-create-info时）
INDEX：若 dump 含
CREATE INDEX，需此权限
LOCK TABLES：部分 dump 场景（如未用
--single-transaction）会显式加锁
典型最小化授权示例（针对数据库
myapp）：
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, LOCK TABLES ON `myapp`.* TO 'restore_user'@'%';
使用 mysqlpump
或 mydumper
恢复时权限是否有差异
有差异。
mysqlpump（MySQL 5.7+）默认并行导出，恢复时若启用
--set-gtid-purged=OFF或涉及
mysql系统库，可能触发额外权限校验；
mydumper是第三方工具，其恢复脚本（
myloader）本身不校验权限，但执行 SQL 时仍受 MySQL 服务端权限控制。
mysqlpump --skip-definer可避免因
DEFINER用户不存在导致的权限拒绝
myloader默认不自动
CREATE DATABASE，需提前建库或加
-d参数指定目录，否则报错与权限无关，而是路径或库不存在 GTID 环境下恢复需
REPLICATION CLIENT权限（查看
gtid_executed），否则
SET GTID_PURGED语句会失败
从 binlog 恢复时容易被忽略的权限点
用
mysqlbinlog解析后重放，核心不是“导入”，而是“执行 SQL”，所以权限要求和普通 SQL 执行一致，但有两个特殊点： 若 binlog 中含
CREATE USER、
GRANT等 DDL，需
CREATE USER和
GRANT OPTION权限 —— 这两点常被遗漏 启用
binlog_format = ROW时，
mysqlbinlog --base64-output=DECODE-ROWS输出的是伪 SQL，实际执行仍走 row-based 逻辑，权限校验发生在 event 解析阶段，而非语句文本层面 时间点恢复（
--start-datetime/
--stop-datetime）不增加权限需求，但若跨 GTID 集合，需
REPLICATION SLAVE权限才能查询
performance_schema.replication_applier_status_by_coordinator（仅调试用，非恢复必需）
真正卡住的往往不是权限，而是 binlog 事件里隐含的库表不存在、字符集不匹配、外键约束冲突 —— 这些问题权限再高也解决不了。
