必须在my.cnf的[mysqld]段设local_infile=OFF并重启，同时配secure_file_priv=NULL、回收FILE权限，并验证SELECT @@local_infile返回0及LOAD DATA LOCAL INFILE报ERROR 1148。
怎么在my.cnf里正确关掉local_infile
只写local_infile = OFF不够，必须确保它落在[mysqld]段，且没有被其他配置覆盖。很多线上环境出问题，是因为把这行错写进[mysql]或[client]段——那只是影响客户端默认行为，服务端照样接受LOAD DATA LOCAL INFILE请求。
编辑/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，在[mysqld]下加：
local_infile = OFF
别漏掉secure_file_priv——它和local_infile是两套机制，但都得配：
-
secure_file_priv = NULL（彻底禁用服务端读文件）或设为受限目录如/var/lib/mysql-files/ -
secure_file_priv不能留空或设为/，否则等于开放整个磁盘 - 设了
secure_file_priv后必须重启mysqld，SET GLOBAL动态设置无效
为什么改完配置还得验证SELECT @@local_infile
配置文件写了≠生效。常见失效场景包括：Docker容器没挂载对配置路径、RDS参数组没点“应用”、K8s initContainer覆盖了主配置。光看文件内容没用，连上MySQL执行：
SELECT @@local_infile;
返回0或OFF才算真关掉。如果返回NULL或空结果，说明local_infile变量根本没加载——大概率是配置段落写错了位置。
再补一刀测试：
LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE t;
必须报错ERROR 1148 (42000)，而不是权限错误或表不存在——前者说明客户端和服务端都拦截了，后者说明只是没权限或表问题，local_infile可能还开着。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
PHP/Python连接时还要手动关local_infile
服务端关了，客户端库仍可能默认开启local_infile，尤其老项目。这不是bug，是历史兼容行为。
- PHP
mysqli：必须在mysqli_real_connect()前调用mysqli_options($conn, MYSQLI_OPT_LOCAL_INFILE, false) - Python
pymysql：初始化时显式传local_infile=False，漏掉就白配 - Java
Connector/J：URL里别带&allowLoadLocalInfile=true，8.0+默认false但可被覆盖
Web应用最容易踩坑：ORM封装层或DB连接池里硬编码了local_infile=True，配置文件关得再严也没用。
secure_file_priv=NULL和FILE权限必须一起动
secure_file_priv = NULL只拦LOAD DATA INFILE和SELECT INTO OUTFILE，拦不住LOAD_FILE()——后者只认FILE权限，不走secure_file_priv校验。
所以必须同步回收权限：
REVOKE FILE ON *.* FROM 'app_user'@'%';
特别检查root账号：SELECT User,Host,File_priv FROM mysql.user WHERE File_priv='Y';，默认带FILE权限但日常运维根本不需要。
验证双保险是否起效：
-
LOAD DATA INFILE '/etc/passwd' INTO TABLE t;→ 报ERROR 1290（secure_file_priv生效） -
SELECT LOAD_FILE('/etc/passwd');→ 返回NULL或明确Access denied（FILE权限回收生效）
漏掉任意一环，攻击者都能绕过。最常被忽略的是：以为secure_file_priv=NULL就万事大吉，忘了FILE权限还在用户身上挂着。
