secure_file_priv仅限制文件操作的物理路径范围，不干预导出内容本身；它无法防止SELECT导出mysql.user表密码哈希、information_schema元数据等敏感信息，必须配合权限回收、字段过滤和视图脱敏才能阻断敏感数据落盘。
直接结论：仅靠设置 secure-file-priv 无法防止导出文件包含敏感系统信息（如密码、密钥、路径），它只控制 MySQL 允许读写文件的**物理目录范围**，不干预 SQL 导出内容本身。
secure-file-priv 是什么，它管不了什么
这个参数是 MySQL 的安全围栏，作用是限制 SELECT ... INTO OUTFILE、LOAD DATA INFILE、LOAD_FILE() 等语句能访问的文件系统路径。它不检查你 SELECT 出来的数据里有没有 'root:password@127.0.0.1' 这种字符串，也不阻止你把 information_schema.PROCESSLIST 或 mysql.user 表导出来——只要目标路径在白名单内，导出就成功。
常见误解是“设了 secure-file-priv 就安全了”，其实它只解决“能不能写到 /etc/shadow”这种越权写入问题，和“导出内容是否含敏感字段”完全无关。
为什么导出文件仍会泄露系统信息
导出操作本身不经过脱敏逻辑。以下情况极易导致敏感信息落盘：
- 执行
SELECT * FROM mysql.user→ 导出明文密码哈希（authentication_string字段虽加密，但可被离线爆破） - 导出
information_schema.TABLES或SCHEMATA→ 暴露数据库名、表名、引擎类型等架构细节 - 导出含
@@hostname、@@datadir、@@socket的查询结果 → 泄露服务器路径与配置 - 应用层拼接 SQL 时带入环境变量或配置片段（如
CONCAT('DB_HOST=', @@hostname)）
真正该做的：导出前过滤 + 权限隔离
防止导出含敏感信息，必须在内容生成阶段干预，而不是依赖文件路径锁：
- 禁止非 DBA 账户访问
mysql、information_schema、performance_schema库：REVOKE SELECT ON mysql.* FROM 'app_user'@'%'; - 导出业务数据时，显式列出字段，避开敏感列：
SELECT id, name, email_masked FROM users，而非SELECT * - 用视图封装脱敏逻辑：
CREATE VIEW v_users AS SELECT id, name, REGEXP_REPLACE(phone, '(\d{3})\d{4}(\d{4})', '\1****\2') AS phone_masked FROM users; - 若必须导出元数据，先用临时表清洗：
CREATE TEMPORARY TABLE clean_info AS SELECT table_schema, table_name FROM information_schema.TABLES WHERE table_schema NOT IN ('mysql', 'performance_schema');
secure-file-priv 配置本身的坑
这个参数值设错反而会引发运维故障：
- 设为空字符串（
secure-file-priv = ""）→ 彻底禁用所有文件导入导出功能，很多备份脚本直接失败 - 设为
/tmp/但未确保 MySQL 进程对该目录有写权限 →ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option... - 设为
/var/lib/mysql-files/后忘记同步 SELinux 上下文或 AppArmor 规则 → 写入被内核拦截，错误日志里只显示“Permission denied” - 修改后未重启 mysqld 或未验证生效：
SELECT @@secure_file_priv;必须返回预期路径，不能是NULL
最常被忽略的一点：即使 secure-file-priv 锁死了路径，攻击者仍可通过 INTO DUMPFILE（单行二进制写入）绕过部分限制，或利用 UDF、插件、日志功能间接导出——所以核心防线永远在“不让敏感数据进入结果集”，而不是“不让结果集写到某目录”。
