你不能“修复” secure_file_priv 配置风险，只能明确选择一种策略并严格执行——要么禁用所有文件操作（NULL），要么限定到最小必要目录，绝不能留空或设为全局可写；查当前值是前提，返回NULL则完全禁止，路径则仅限该目录，空字符串在8.0.28+已不支持，改配置必须重启且目录权限需mysql属主、绝对路径、显式存在。
你不能“修复” secure_file_priv 配置风险，只能明确选择一种策略并严格执行——要么禁用所有文件操作（NULL），要么限定到最小必要目录，绝不能留空或设为全局可写。
查 secure_file_priv 当前值是所有操作的前提
连上 MySQL 后第一件事就是确认它实际生效的值，不是看配置文件写了什么：
-
SHOW VARIABLES LIKE 'secure_file_priv';返回NULL：所有SELECT ... INTO OUTFILE、LOAD DATA INFILE、LOAD_FILE()全部被硬性拒绝，FILE权限也无效 - 返回具体路径（如
/var/lib/mysql-files/）：只允许读写该路径下的文件，子目录必须显式存在且属主为mysql:mysql - 返回空字符串
''：MySQL 8.0.28+ 已移除支持，若看到此值，说明服务启动时忽略该配置或版本不兼容，实际行为不可靠
改配置后仍无效？大概率是没找对配置文件或没重启
MySQL 在 Windows 和 Linux 上读取配置文件的顺序不同，且只加载第一个匹配项，不会合并多个文件：
- Windows 下常见路径：
C:\ProgramData\MySQL\MySQL Server 8.0\my.ini（隐藏目录）、C:\Windows\my.ini、安装目录下的my.ini；Linux 下通常是/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf - 用
mysql --help | grep "Default options"查 MySQL 实际加载的配置路径（Linux/macOS），Windows 可在服务属性里看启动参数 - 修改后必须完整重启服务：
sudo systemctl restart mysql（Linux）或net stop mysql && net start mysql（Windows），仅 reload 不生效 - Docker 用户需注意：
secure_file_priv是启动时读取的，挂载新配置文件后必须重建容器，不能只docker exec进去改
路径和权限必须同时满足，缺一不可
即使配置写了 secure_file_priv = /data/export，只要以下任一条件不满足，执行仍报 ERROR 1 (HY000)：
- 目录
/data/export必须已存在，且由mysql用户拥有：sudo chown mysql:mysql /data/export -
SELECT ... INTO OUTFILE必须用绝对路径，且必须落在secure_file_priv指定目录内：SELECT * INTO OUTFILE '/data/export/user.txt' FROM user; -
LOAD DATA INFILE路径是相对于secure_file_priv目录的，不能带前导/：LOAD DATA INFILE 'data.csv' INTO TABLE mytable;（前提是data.csv在/data/export/data.csv） - 文件本身也要属主为
mysql：sudo chown mysql:mysql /data/export/data.csv，否则LOAD DATA会失败
Docker 和小皮面板环境最容易漏掉权限映射
本地开发常以为“进容器改完配置就 OK”，但实际权限链更长：
- Docker 启动时未挂载对应目录，容器内路径存在但宿主机无对应目录或权限，MySQL 进程仍无法写入
- 小皮面板（phpstudy_pro）等集成环境自带 MySQL 服务，修改自己写的
my.ini无效，必须找到面板实际加载的配置文件（通常在PHPTutorial\MySQL\conf\my.ini） - Windows 下用管理员身份编辑
my.ini后，若文件保存时权限被重置（如变成只读或属主为SYSTEM），MySQL 服务启动时会静默跳过该配置 - SELinux 或 AppArmor 启用时，即使目录权限正确，也会拦截写入，需额外放行：
sudo setsebool -P mysqld_disable_transitional 1（RHEL/CentOS）
真正卡住人的从来不是“怎么配”，而是 MySQL 进程在操作系统层面到底有没有那个目录的写权限——这一步跳过，后面全白忙。
