MySQL 8.0+中迁移工具账号不应授SUPER和FILE权限，因SUPER已被细粒度权限替代且常静默失效，FILE仅限本地文件操作且有安全风险；应按阶段授予SELECT、REPLICATION CLIENT/SLAVE、DDL等最小必要权限，并确保host精确匹配。
给数据迁移工具账号授最高权限，不是简单加 SUPER 和 FILE 就完事——这两个权限在现代 MySQL（尤其是 8.0+）中已被严格限制或弃用，盲目授予反而导致连接失败或权限静默失效。
为什么 SUPER 在 MySQL 8.0+ 中基本不能用了
MySQL 8.0 废除了 SUPER 的大部分能力，拆分为细粒度动态权限（如 SET_USER_ID、ENCRYPTION_KEY_ADMIN 等）。直接执行 GRANT SUPER ON *.* TO 'dts'@'%'; 虽不报错，但实际无法替代旧版行为：
- 它不再允许跳过二进制日志写入、修改全局变量（如
sql_log_bin）、或绕过 DML 审计规则 - 若目标库启用了
require_row_format=ON或审计插件，SUPER用户仍会被拦截 - 某些云数据库（如 PolarDB、RDS）已彻底屏蔽
SUPER，授权语句执行成功但无任何效果
FILE 权限根本不能用于远程迁移工具
FILE 是服务器端文件读写权限，仅作用于 MySQL 进程能访问的本地路径（如 /var/lib/mysql/），和“从客户端上传 SQL 文件”或“通过网络拉取数据”完全无关：
- 迁移工具（如 Data Transmission Service、mysqldump、pt-table-sync）走的是网络协议，不依赖
LOAD DATA INFILE或SELECT ... INTO OUTFILE - 授予
FILE反而带来严重风险：攻击者可利用SELECT ... INTO OUTFILE读取任意可读文件（如/etc/passwd） - MySQL 8.0 默认禁用
secure_file_priv，即使有FILE权限，INTO OUTFILE也会报错ERROR 1290 (HY000)
真正需要的迁移高权限组合（按场景）
不同迁移阶段要的权限完全不同，硬塞一个“最高权限”账号反而埋雷：
-
结构 + 全量迁移：只需
SELECT（所有待迁库表）、SHOW VIEW、LOCK TABLES（若未设--skip-lock-tables） -
增量（Binlog）迁移：必须
REPLICATION CLIENT（查 master status） +REPLICATION SLAVE（拉取 binlog event），缺一不可 -
自动建库建表：需
CREATE、ALTER、DROP、INDEX、CREATE VIEW等 DDL 权限，范围限定在目标库（如GRANT CREATE, ALTER ON `target_db`.* TO 'dts'@'%'） -
跨库对象引用（如触发器、函数）：额外加
EXECUTE和TRIGGER，但禁止授予*.*全局级
别碰 SUPER 和 FILE 的替代方案
当迁移工具报“权限不足”时，优先检查具体错误，而不是惯性加 SUPER：
- 报
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s)→ 实际是缺REPLICATION CLIENT或BACKUP_ADMIN（8.0.22+ 替代部分SUPER功能） - 报
ERROR 1045 (28000): Access denied for user→ 检查账号 host 匹配（'dts'@'10.20.%'≠'dts'@'%'），不是权限问题 - 需要临时禁用 binlog 写入（如避免迁移过程产生冗余日志）→ 改用会话级设置：
SET SESSION sql_log_bin = 0;（只要账号有SESSION_VARIABLES_ADMIN即可，无需SUPER）
最易被忽略的一点：迁移工具账号的 host 必须精确匹配连接来源 IP 段，'dts'@'%' 在启用了 skip-name-resolve 的实例上可能完全不生效——此时必须写成 'dts'@'172.16.%.%' 这类 CIDR 格式，否则连认证环节都过不去。
