source导入报“权限不足”根本不是缺file权限，而是目标数据库缺少create、drop、insert等库级权限；需显式授权grant create, drop, insert on myapp_db.*，并注意路径、编码及权限层级匹配。
source导入报“权限不足”根本不是缺FILE权限
绝大多数人看到报错里带Access denied或command denied，第一反应是去授FILE或SUPER——这几乎总是错的。source命令走的是客户端本地文件读取流程，MySQL服务端根本不参与文件I/O，所以FILE权限完全不生效。真正卡住的，是SQL脚本里那些CREATE、DROP、INSERT语句在目标库上没被授权。
为什么SHOW GRANTS显示有权限却还是报错
因为MySQL权限检查是分层的：你执行mysql -u user -p myapp_db时，MySQL会严格检查myapp_db这个库是否对当前用户显式授予了DDL/DML权限，而不是看*.*通配符有没有覆盖。
- 常见现象：
SHOW GRANTS FOR 'user'@'host';显示GRANT ALL ON *.*，但source /x.sql一遇到CREATE TABLE就报ERROR 1142 - 真实原因：权限只给了全局
*.*，而导入指定了库名myapp_db，MySQL拒绝回退到通配符匹配 - 修复方式：
GRANT CREATE, DROP, INSERT ON `myapp_db`.* TO 'user'@'host'; FLUSH PRIVILEGES;（注意反引号包裹库名） - 如果SQL里含
CREATE DATABASE，还得额外加GRANT CREATE ON *.*
source路径和字符集问题常被误判为权限错误
报错信息不明确时，容易把底层失败当成权限问题。比如Failed to open file其实是shell层文件读取失败，Unknown command大概率是编码不一致导致分号解析异常。
-
source路径必须是绝对路径，或相对于你启动mysql命令时所在的shell目录——不是MySQL安装目录，也不是~ - 若SQL文件是UTF-8 BOM格式，MySQL客户端可能把BOM当非法字符，报语法错误，看起来像权限拒绝
- 连接时没指定字符集：
mysql -u user -p --default-character-set=utf8mb4比进客户端再SET NAMES更可靠 - 文件属主是root，而你用普通用户运行
mysql客户端，也会触发Failed to open file，和MySQL用户权限无关
云数据库或受限环境里授FILE/SUPER反而会让问题更糟
阿里云RDS、腾讯云CDB等默认禁用FILE且不可开启，但照样能用source或重定向导入——这直接证明它不是必需项。盲目授SUPER更危险：它只在极少数场景触发（如SQL里硬写SET GLOBAL），而审计系统会立刻标红高危权限。
- 你的SQL文件不含
SET GLOBAL、RESET MASTER、CREATE DEFINER，就完全不需要SUPER - 授了
FILE但问题还在？说明根源压根不在那里，继续排查库级权限或路径/编码 - 最小权限原则不是空话：给
myapp_db精确授权，比GRANT ALL ON *.*安全得多，也更容易定位问题
实际操作中最容易被忽略的，是权限层级与导入命令中指定的库名必须严格对应——哪怕只差一个反引号、一个空格，MySQL都会拒绝匹配。
