file权限本身不提供导入导出能力，仅允许mysql进程读写服务端本地文件，必须配合select权限和secure_file_priv路径限制才可能安全使用。
不能直接“给用户分配FILE权限来执行导入导出”——FILE权限本身不等于导入导出能力，它只是打开服务器文件系统的一个高危入口，必须配合SELECT权限和secure_file_priv路径限制才可能安全使用。
为什么单授 FILE 权限根本导不出数据
FILE权限只允许MySQL进程读写服务端本地文件，但不提供读取表数据的能力。常见错误是只执行GRANT FILE ON *.* TO 'user'@'%'，结果一执行SELECT * INTO OUTFILE就报错ERROR 1142 (42000): SELECT command denied。
- 必须同时授予
SELECT权限（针对具体库或表，如GRANT SELECT ON sales_db.* TO 'exporter'@'192.168.5.%'） -
FILE只能用*.*授予，无法限定到库或表，这是硬性限制 - 没有
SELECT，INTO OUTFILE连源数据都拿不到；没有FILE，即使能查也写不出文件
secure_file_priv没设好，FILE权限等于白给
检查当前配置：SHOW VARIABLES LIKE 'secure_file_priv';。如果返回NULL或空字符串''，那SELECT INTO OUTFILE会直接失败或完全失控。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
NULL：禁止所有INTO OUTFILE和LOAD DATA INFILE操作 -
''（空字符串）：允许写入任意路径——等同于把服务器磁盘钥匙交出去 - 推荐值如
/var/lib/mysql-files/：必须手动创建该目录，并确保mysql系统用户有读写权限 - 该参数在
my.cnf的[mysqld]段设置，修改后必须重启MySQL才生效
建账号时最容易踩的三个坑
很多线上事故源于建号流程不严谨。不是“能跑通就行”，而是权限边界必须清晰。
- 别用
@'%'：host匹配规则会让更宽泛的记录（如@'localhost'）覆盖你精细设置的@'10.10.20.%'，导致权限意外失效 - 别漏
FLUSH PRIVILEGES;：尤其在非root账户下直接改mysql.user表后，不刷新权限不会生效 - 别留
GRANT OPTION：它允许用户把FILE权限再转授他人，绕过你的管控，务必显式REVOKE GRANT OPTION ON *.* FROM 'exporter'@'192.168.5.%'
替代方案比硬开 FILE 更常用也更安全
绝大多数批量导出场景其实根本不需要FILE权限——比如用mysqldump、mysqlpump或应用层API导出，都是客户端拉数据，服务端不碰磁盘文件。
-
mysqldump只需SELECT+LOCK TABLES（或--single-transaction规避锁） - 云数据库（RDS/PolarDB）通常默认禁用
FILE且不允许改secure_file_priv，但照样支持mysqldump导入导出 - 真正需要
FILE的场景极少：比如定时任务在服务端生成CSV供下游系统直接读取，且无法走网络协议
FILE权限的本质不是“导出功能开关”，而是“MySQL进程以自身身份访问服务器文件系统的开关”。一旦开了，风险不在SQL语句里，而在路径控制是否彻底、账号host是否精确、其他高危权限是否被清理干净——这些细节漏掉一个，就不是导不出数据的问题，而是服务器被横向渗透的问题。
