根本原因是MySQL的secure_file_priv限制和系统级权限双重拦截：若该变量为NULL则完全禁用导出；若为具体路径则仅允许写入该目录，且MySQL进程（如mysql用户）须对该路径有写权限，并绕过SELinux/AppArmor等安全模块拦截。
根本原因就两个：MySQL 服务进程没权限写目标路径，或者压根不被允许往任意路径写——secure_file_priv 拦住了你。不是 SQL 写错了，也不是数据有问题。
查 secure_file_priv 是不是 NULL 或空值
这是最常卡住人的第一关。运行：
SHOW VARIABLES LIKE 'secure_file_priv';
如果返回 NULL，说明 MySQL 已彻底禁用 SELECT INTO OUTFILE 和 LOAD DATA INFILE；如果返回空字符串（''），现代 MySQL 版本通常会直接拒绝启动或报错；只有返回一个具体路径（比如 /var/lib/mysql-files/）才算可操作。
- 若为
NULL：必须修改配置文件（如/etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]下加一行secure_file_priv = /var/lib/mysql-files，然后sudo systemctl restart mysql - Windows 上常见路径是
C:ProgramDataMySQLMySQL Server 8.0Uploads，注意反斜杠要写成双反斜杠或正斜杠 - 改完务必重启 mysqld，只 reload 配置不生效
FILE 权限没给够
SELECT INTO OUTFILE 不看你是哪个用户登录的，它只认 MySQL 用户账号是否拥有全局 FILE 权限。没有这个权限，哪怕路径完全合法也会报 ERROR 1227 (42000)。
- 检查当前用户权限：
SHOW GRANTS FOR CURRENT_USER;或SHOW GRANTS FOR 'your_user'@'%'; - 授予权限（需 root 或具备
GRANT OPTION的用户执行）：GRANT FILE ON *.* TO 'your_user'@'%'; FLUSH PRIVILEGES; -
FILE是全局权限，不能限定到某个数据库或表
目标目录的系统级权限和 SELinux/AppArmor 拦路
即使 secure_file_priv 指向了 /var/lib/mysql-files，MySQL 进程（通常是 mysql 用户）也得有该目录的写权限，且不能被安全模块拦截。
- 确认目录归属和权限：
ls -ld /var/lib/mysql-files，应类似drwxr-xr-x 2 mysql mysql；如果不是，执行sudo chown mysql:mysql /var/lib/mysql-files和sudo chmod 755 /var/lib/mysql-files - CentOS/RHEL 系统大概率是 SELinux 在作祟：临时关闭验证
sudo setenforce 0，若导出成功，说明是 SELinux 策略问题，需调整上下文或放行mysqld_t对该路径的写权限 - Ubuntu/Debian 常见 AppArmor 拦截：编辑
/etc/apparmor.d/usr.sbin.mysqld，在/var/lib/mysql-files/** rwk,行后追加你实际要用的路径（如/tmp/** rwk,），再执行sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld
导出路径必须严格匹配 secure_file_priv 设置
MySQL 不会帮你自动补路径、也不会做相对路径解析。哪怕只差一个字符，或者用了符号链接，都会报 Can't create/write to file（Errcode: 13）。
- 路径必须以
secure_file_priv返回的值开头，且完整一致。例如设置的是/var/lib/mysql-files，就不能写成/var/lib/mysql-files/（末尾多斜杠可能失败）、也不能写./data.csv（相对路径非法） - Windows 上路径分隔符必须用正斜杠或双反斜杠：
C:/temp/data.csv或C:\temp\data.csv，单反斜杠会被解析为转义字符 - 导出文件名不能含非法字符（如
*、?、:），也不能是已存在的同名目录
真正麻烦的从来不是语法，而是 MySQL 进程身份、系统权限、安全模块、配置变量这四层嵌套限制。漏掉任何一层，INTO OUTFILE 就会静默失败——连日志都不一定报清楚到底卡在哪一环。
