mysqldump 备份时需要哪些最小权限
仅执行备份操作，
SELECT权限不是万能的——它必须配合
LOCK TABLES（对单库备份）或
RELOAD（启用
--single-transaction时触发
FLUSH TABLES WITH READ LOCK）才能避免备份过程中数据不一致。但实际中更推荐用
--single-transaction配合事务隔离，此时只需
SELECT+
REPLICATION CLIENT（用于获取 binlog 位置，非必需）+
SHOW VIEW（若库含视图）。
PROCESS权限仅在需导出当前连接状态（
--all-databases或
--flush-logs）时才需要。
最小权限示例：
GRANT SELECT, LOCK TABLES ON `mydb`.* TO 'backup_user'@'%'; -- 或更安全的事务方式（InnoDB 表）： GRANT SELECT ON `mydb`.* TO 'backup_user'@'%';
mysql 命令行恢复时权限不足的典型报错
执行
mysql -u user -p mydb 时常见报错：<code>ERROR 1142 (42000) at line X: CREATE command denied to user或
DROP command denied。这说明恢复用户缺少
CREATE、
DROP、
ALTER、
INSERT、
INDEX等 DDL/DML 权限。尤其注意：
CREATE VIEW、
CREATE ROUTINE、
ALTER ROUTINE在含视图/存储过程的备份中必须显式授权。
恢复前应确保用户具备：
CREATE,
DROP,
ALTER对目标数据库
INSERT,
UPDATE,
DELETE（部分 dump 含
INSERT语句）
CREATE VIEW和
SHOW VIEW（若备份含视图）
CREATE ROUTINE（若含存储过程/函数）
授权命令示例：
GRANT CREATE, DROP, ALTER, INSERT, UPDATE, DELETE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE ON `mydb`.* TO 'restore_user'@'%';
使用 mysqlpump 替代 mysqldump 时的权限差异
mysqlpump是 MySQL 5.7+ 提供的并行逻辑备份工具，但它对权限要求更严格：默认启用
--add-drop-table和并行导出，会主动查询
INFORMATION_SCHEMA元数据，因此除基础 DML 权限外，还强制要求
SELECT权限作用于
INFORMATION_SCHEMA库（MySQL 8.0+ 默认禁止跨库
SELECT到系统库）。若未授权，会报错：
Access denied for user ... to database 'INFORMATION_SCHEMA'。
解决方法只有两个：
显式授予：GRANT SELECT ON INFORMATION_SCHEMA.* TO 'backup_user'@'%';禁用元数据访问（不推荐）：
mysqlpump --skip-definer --skip-triggers --no-views，但这会丢失 DEFINER、触发器、视图定义
另外，
mysqlpump恢复时仍依赖目标库的写权限，与
mysql命令无本质区别。
生产环境备份账号不应拥有 SUPER 或 GRANT OPTION
很多 DBA 为省事直接给备份账号
SUPER权限，这是高危操作：
SUPER可动态修改全局变量（如
sql_log_bin=OFF）、终止任意线程、绕过所有权限检查。一旦该账号凭证泄露，攻击者可关闭 binlog、清空 slow log、甚至 kill 主从复制线程。
同样，
GRANT OPTION允许该账号把自身权限再授给他人，形成权限扩散链。真实生产中应严格遵循最小权限原则： 备份账号只赋予具体数据库的
SELECT+
LOCK TABLES或
RELOAD恢复账号只赋予目标数据库的
CREATE/
DROP/
INSERT等必要 DDL/DML 权限 绝不分配
SUPER、
GRANT OPTION、
FILE（防读取服务器文件） 账号限制来源 IP：
'backup_user'@'192.168.10.5'，而非通配符
'%'
权限失控往往不出现在备份脚本里，而出现在账号生命周期管理——比如临时开通的权限未及时回收，或者测试环境账号被误用于生产。
