撤回 FILE 权限并设置 secure_file_priv = NULL 是禁用 SELECT INTO OUTFILE 的最有效方式；需同时关闭 local_infile 并通过网络与终端策略防范客户端导出。
FILE 权限是 SELECT INTO OUTFILE 的硬门槛
只要用户有 FILE 权限，哪怕只给了 SELECT，也能执行 SELECT ... INTO OUTFILE 导出任意查询结果——这不是表级权限能控制的。MySQL 把文件读写当作独立于 DML 的全局能力，所以撤回 FILE 是第一步，也是最有效的一步。
常见错误是只 revoke SELECT 或限制库表权限，却漏掉 FILE；或者误以为 GRANT SELECT ON db.* 会隐含导出能力（它不会），结果用户仍能导出。
-
REVOKE FILE ON *.* FROM 'user'@'host';必须用*.*，不能写成db.*或db.table - 若用户属于角色（MySQL 8.0+），需检查
SHOW GRANTS FOR ROLE 'role_name';，并从角色中也REVOKE FILE - 执行后必须
FLUSH PRIVILEGES;，否则权限变更不生效
secure_file_priv 设为 NULL 才真正禁用导出功能
secure_file_priv 不是开关，而是路径白名单。设为空字符串 '' 相当于放开所有路径，极度危险；设为具体目录（如 /var/lib/mysql-files）只是把导出限制在该目录下，但导出行为本身仍可用。
要让 SELECT ... INTO OUTFILE 语句直接报错，必须设为 NULL（MySQL 8.0.17+ 支持），或设为空值（''）并配合 FILE 权限已撤回——否则 MySQL 启动会失败。
- 在
my.cnf的[mysqld]段添加：secure_file_priv = NULL - 修改后必须重启
mysqld，SET GLOBAL secure_file_priv = NULL动态设置无效 - 验证方式：
SELECT @@secure_file_priv;返回NULL即生效
命令行导出绕过 secure_file_priv 的风险
用户用 mysql -e "SELECT ..." > output.csv 或 mysqldump 导出全库，完全不走 INTO OUTFILE 流程，因此不受 secure_file_priv 和 FILE 权限限制——这是服务端导出和客户端导出的本质区别。
这类操作依赖的是用户的连接权限和表级 SELECT 权限，无法通过数据库配置直接禁止，只能靠外部手段收敛：
- 业务账号不给
SELECT权限，只提供 API 或中间件代理访问 - 连接池/中间件（如 ProxySQL、ShardingSphere）统一拦截高危语句，或限制单次返回行数
- 审计日志开启
general_log或使用 MySQL Enterprise Audit，监控高频SELECT+ 大结果集行为
local_infile 是另一个常被忽略的导入通道
LOAD DATA LOCAL INFILE 允许客户端上传本地文件到服务端，它不依赖 FILE 权限，但需要客户端和服务端都启用 local_infile。很多默认安装或连接驱动（如 JDBC、PyMySQL）会自动开启它，构成数据反向泄露入口。
彻底关闭需两端同步动作：
- 服务端：在
my.cnf加local_infile = 0，或运行SET GLOBAL local_infile = 0;（需 SUPER 权限） - 客户端连接时显式禁用：如 mysql 命令加
--local-infile=0，JDBC URL 加&allowLoadLocalInfile=false - 验证是否关闭：
SELECT @@local_infile;应返回OFF
真正难防的不是 INTO OUTFILE，而是用户手握 SELECT 权限 + 客户端工具 + 网络可达性——这时候导出控制就从数据库层上移到了网络策略、终端管控和访问审计层面。
