真正要堵的是“谁有权限查什么”和“能导出到哪”，secure_file_priv仅限物理写入路径，对mysqldump、客户端导出、复制粘贴、应用层写文件等完全无效。
不能只靠 secure_file_priv 拦截导出路径，它不管内容是否敏感，也不防 SELECT 后手动复制粘贴——真正要堵的是“谁有权限查什么”和“能导出到哪”。
为什么设了 secure_file_priv 还会泄露数据
这个参数只限制 SELECT ... INTO OUTFILE、LOAD DATA INFILE 等语句的**物理写入路径**，对以下行为完全无效：
-
mysqldump导出：不走secure_file_priv，只要账号有权限就能执行 - 客户端工具（DBeaver/Navicat）点“导出为 CSV”：数据经网络传到本地，MySQL 服务器无感知
-
SELECT * FROM mysql.user→ 复制结果粘贴进 Excel：绕过所有服务端路径控制 - 应用层连库后
fetchall()写文件：属于业务代码行为，不在数据库管控范围内
必须禁用非必要账号的 FILE 权限和系统库访问
导出敏感数据的前提是能查到敏感数据。开发人员账号若还能访问 mysql、information_schema，等于给了他们自动生成“数据库地图”的钥匙。
- 立即回收：
REVOKE FILE ON *.* FROM 'dev_user'@'%';（FILE权限是提权链关键一环，99% 的开发场景根本不需要） - 禁止查系统表：
REVOKE SELECT ON mysql.* FROM 'dev_user'@'%';、REVOKE SELECT ON information_schema.* FROM 'dev_user'@'%'; - 验证是否生效：
SHOW GRANTS FOR 'dev_user'@'%';，确认输出里没有FILE和mysql.* - 注意 root 账号：即使生产环境保留 root，也应单独
REVOKE FILE，别让它成为默认配置的盲区
导出业务数据时必须显式指定字段，禁用 SELECT *
开发习惯性写 SELECT * 是数据泄露温床——一旦表结构新增身份证、手机号、密钥字段，旧导出逻辑立刻开始漏数据。
- 在 SQL 审计规则或 CI/CD 检查脚本中加入关键词拦截：
grep -q "SELECT \*" *.sql或正则匹配SELECT\s+\* - 强制使用视图脱敏：
CREATE VIEW v_users AS SELECT id, name, SUBSTR(phone, 1, 3) AS phone_prefix FROM users;，只给开发查视图权限 - DBA 审批导出需求时，必须明确写出字段列表，拒绝 “导出全量用户表” 这类模糊申请
- 自动化导出脚本开头加校验：
mysql -h $HOST -e "SELECT COUNT(*) FROM (SELECT id, email FROM users LIMIT 1) t;"，确保语句不含通配符
客户端工具和终端连接本身就要设防
再严的 SQL 层控制，也挡不住开发用 DBeaver 连上生产库后右键“Export Resultset”。这类操作发生在客户端，服务端只看到普通 SELECT 请求。
- 生产环境 MySQL 配置中启用
sql_safe_updates=1，虽不防导出，但能拦住无 WHERE 的误删改，降低连错库后的破坏半径 - IDE / 终端提示符强制显示环境标识：比如 Bash 的
PS1包含$(hostname | grep -q prod && echo "[PROD]" || echo "[DEV]") - 禁止开发人员直接使用生产账号连接 GUI 工具；统一走跳板机 + 临时凭证，连接前需二次审批
- 审计日志必须开启并导出到独立 SIEM：
SELECT语句本身不敏感，但高频查询users表 + 大量LIMIT 10000组合就是风险信号
最易被忽略的一点：导出控制不是纯数据库问题。当开发能连上生产库执行任意 SELECT，而你又没在应用网关或代理层做字段级访问控制，那所有“防导出”动作都只是减缓泄露速度，而非阻断泄露可能。
