彻底禁用导入导出能力须撤回全局FILE权限：执行REVOKE FILE ON . FROM 'user'@'host';、FLUSH PRIVILEGES;，并检查角色继承；secure_file_priv仅限路径，不能替代权限回收。
为什么 LOAD DATA 和 SELECT ... INTO OUTFILE 会绕过常规权限控制
MySQL 的数据导入导出操作（如 LOAD DATA INFILE、SELECT ... INTO OUTFILE）不依赖普通表级权限（如 SELECT 或 INSERT），而是由两个独立全局权限控制：FILE 权限。只要用户拥有该权限，就能从服务端文件系统读写任意可访问路径（受 secure_file_priv 限制）。这意味着即使你已收回所有数据库操作权限，只要没显式撤销 FILE，用户仍可能通过文件读写泄露或篡改数据。
如何彻底禁用用户的导入导出能力
核心是移除 FILE 权限，并确认其无法被重新授予。操作分三步：
- 执行
REVOKE FILE ON *.* FROM 'username'@'host';—— 注意必须是ON *.*，因为FILE是全局权限，不能作用于单库或单表 - 运行
FLUSH PRIVILEGES;确保权限立即生效（尤其在直接修改mysql.user表后） - 检查是否仍有隐式继承：若用户属于角色（MySQL 8.0+），需同时从角色中撤回
FILE，或确保该角色本身未被授予FILE
验证方式：以该用户登录后执行 SELECT ... INTO OUTFILE '/tmp/test.txt';，应报错 ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement 或更明确的 ERROR 1045 (28000): Access denied for user ... (using password: YES)（后者说明 FILE 已失效）。
secure_file_priv 不是替代方案，只是辅助防线
设置 secure_file_priv='/var/lib/mysql-files' 只能限制读写路径范围，不能禁止操作本身。只要用户有 FILE 权限，仍可在该目录下读取配置文件、写入 Webshell（若 Web 目录可被该路径覆盖）、或导出敏感表结构。它解决的是“能读哪”，而非“能不能读”。因此：
- 不要依赖
secure_file_priv来代替权限回收 - 若业务完全不需要导入导出，建议设为
secure_file_priv=''（空值）或NULL（MySQL 8.0.17+），此时所有LOAD DATA和INTO OUTFILE语句直接报错，但前提是FILE权限也已被撤回，否则启动时会失败 - 修改此变量需重启 MySQL 或使用
SET PERSIST secure_file_priv = '';（仅限支持持久化变量的版本）
应用连接池或中间件场景下的隐藏风险
很多应用使用连接池（如 HikariCP、Druid）或 SQL 中间件（如 ProxySQL、ShardingSphere），它们常以高权限账号建连，再通过会话级变量或注释模拟用户上下文。此时即使业务用户无 FILE 权限，攻击者若能注入 SQL，仍可能利用连接池持有的高权限执行 LOAD DATA。应对方式：
- 连接池使用的数据库账号必须严格遵循最小权限原则，明确不授予
FILE - 在中间件层配置 SQL 黑名单，拦截含
LOAD DATA、INTO OUTFILE、DUMPFILE的语句（注意大小写和空格绕过） - 审计日志中重点关注
Com_load和Com_select中带INTO OUTFILE的查询（可通过general_log或slow_query_log配合正则提取）
SELECT argument FROM mysql.general_log WHERE command_type = 'Query' AND argument LIKE '%INTO OUTFILE%' ORDER BY event_time DESC LIMIT 5;
真正起效的永远是权限回收，其他都是补丁。只要 FILE 权限还在，任何配置或中间层策略都存在被绕过的可能。
