MySQL LOAD DATA LOCAL INFILE 为什么要谨慎开启：从文件边界到双端校验

临时给报表库导入一份CSV时，不少运维和开发图省事，直接在客户端启动参数上加 `--local-infile=1`，看到数据顺利进表就直接收尾。很容易被漏掉的细节是：LOAD DATA LOCAL INFILE 读取的是客户端本地的文件，而且这套导入链路能不能正常跑通，根本不是单改一个开关就能决定的。

把 LOCAL 导入当成一次「客户端文件定向授权」：生产环境默认保持关闭状态；确有导入需求时，只在专属的临时导入会话里开启，同时保证服务端、客户端、文件存放目录三处的操作都可以被后续回溯核查。

先搞清楚文件到底从哪台设备读取

两条导入语句只差了一个 `LOCAL` 关键字，文件的读取边界却完全不一样：

-- 非 LOCAL：文件在 MySQL 服务端
LOAD DATA INFILE '/srv/import/orders.csv'
INTO TABLE orders
FIELDS TERMINATED BY ','
IGNORE 1 LINES;

-- LOCAL：文件在发起 mysql 命令的客户端
LOAD DATA LOCAL INFILE '/srv/import/orders.csv'
INTO TABLE orders
FIELDS TERMINATED BY ','
IGNORE 1 LINES;

第二条语句里写的 `/srv/import/orders.csv` 是客户端侧的路径。你用自己的笔记本运行 mysql，它就会尝试读取你本机上对应路径的文件；你在跳板机上运行同一条语句，读取的就是跳板机存储路径下的文件。这个判断优先级比「数据库账号有没有FILE权限」还要靠前。

MySQL官方把LOCAL特性设计为客户端主动发起的文件传输能力，服务端解析到SQL里的LOCAL关键字后，会主动向客户端发起文件请求，所以如果客户端连接到了不可信的数据库服务端，客户端本地所有可读文件都会变成需要防护的敏感资产。

风险不在导入速度，而在整条请求链路

把一次LOCAL导入拆成四个连贯动作，边界就很清晰了：客户端提交带LOCAL的SQL请求，服务端解析到LOCAL关键字，服务端回源请求读取指定文件，客户端校验路径后读取文件内容上传。只要客户端连接的服务端不可信，或者导入账号和工作目录被混用，就不能把这条链路当成普通的查询语句来对待。

实际项目里最常见的误区有三个：

• 只在服务端打开 `local_infile` 开关，完全没有记录哪些客户端可以使用这个能力。
• 为了兼容某个老旧程序的导入逻辑，把全局配置长期设为ON状态。
• 让导入账号直接在用户主目录下运行，CSV、业务配置文件、密钥文件放在同一个可读范围内。

这不是说LOCAL导入完全不能用，而是要把「谁能读哪类文件」做成可检查的明确配置，而不是开发机上随便就能用的默认行为。

生产环境的最小安全配置

不需要本地导入时：双端全部关闭

先登录服务端确认当前配置值：

SHOW GLOBAL VARIABLES LIKE 'local_infile';

如果业务完全不依赖LOCAL导入能力，保持服务端配置为关闭，同时在命令行客户端显式拒绝本地导入请求：

SET GLOBAL local_infile = OFF;

mysql --local-infile=0 -h db.internal -u report_reader -p reporting

这里的检查结果应当显示服务端变量值为 `OFF`。后续客户端就算误写了带LOCAL的导入语句，也会收到对应错误提示，不会悄悄读取本地文件上传：

ERROR 3950 (42000): Loading local data is disabled;
this must be enabled on both the client and server side

确需导入时：限定会话和文件目录

临时导入不要去修改永久配置文件。可以把待导入的CSV放到专用目录，比如 `/var/tmp/mysql-import/orders-20260726.csv`，先核对目录权限，再只为本次客户端连接单独开启导入能力：

mysql --local-infile=1 \
  --load-data-local-dir=/var/tmp/mysql-import \
  -h db.internal -u import_runner -p reporting

进入数据库会话后先校验双端状态：

SHOW GLOBAL VARIABLES LIKE 'local_infile';
SELECT CURRENT_USER(), DATABASE();

导入完成后先核对数据行数和业务主键范围，再退出客户端，删除临时目录下的导入文件，把服务端的LOCAL能力恢复到关闭状态。如果业务用的是代码连接器而不是原生mysql命令行，也要在连接参数或者驱动配置里找到对应的LOCAL开关，不能只核查MySQL服务端的配置。

导入前后留好可复查的记录

导入操作最少要留存四项信息：操作人、发起导入的客户端主机地址、文件的SHA-256哈希值、导入前后的表行数。文件名可以随意修改，文件哈希才能准确确认「当前导入的就是之前审批过的那份文件」。

sha256sum /var/tmp/mysql-import/orders-20260726.csv
mysql --local-infile=0 -h db.internal -u audit_reader -p reporting \
  -e "SELECT COUNT(*) AS rows_now FROM orders;"

如果导入结果不符合预期，不要急着重新开LOCAL权限反复尝试。先把CSV的哈希值、导入用的SQL语句、错误行明细、事务边界全部留存好，确认问题是列顺序不匹配、换行符异常、字符集不对还是重复键冲突导致的，再决定是回滚数据还是重新生成合规的导入文件。

几个容易混淆的边界说明

• 服务端开了权限不等于客户端就能用：服务端、客户端两端都开启对应权限，导入请求才会执行成功。
• 客户端能用不等于允许读取任意文件：要和命令行参数、临时目录权限配合做限制。
• 单次导入成功不等于配置可以长期敞开：单次任务执行完成后，要立刻把配置恢复到默认关闭状态。
• FILE权限不能覆盖LOCAL的全部管控逻辑：LOCAL读取的是客户端侧文件，还要单独做好客户端文件权限和连接目标的校验。

常见问题

为什么 `LOAD DATA LOCAL INFILE` 报 3950 错误？

大多是服务端 `local_infile` 或者客户端LOCAL能力其中一端处于关闭状态。先分别排查服务端全局变量和客户端启动参数，不要直接把全局配置改成长期开启状态。

MySQL 8.4 默认允许 LOCAL 导入吗？

官方8.4文档中 `local_infile` 的默认值为OFF。实际使用环境里还是要以 `SHOW GLOBAL VARIABLES LIKE 'local_infile'` 的查询结果和客户端实际参数为准。

临时导入结束后只退出mysql客户端够不够？

不够。还要删掉临时存放的CSV文件、确认服务端配置已经恢复、检查导入账号有没有被脚本保存为长期可用状态，留存好文件哈希和最终导入行数记录。

能不能用 LOCAL 导入生产订单表？

可以，但要有明确的专属导入账号、专用存放目录、提前审批过的文件哈希，还有对应的回退方案。如果只是一次性运维任务，优先在权限受控的跳板机上完成操作。

把 LOCAL 当成一次性临时文件授权

MySQL的LOCAL导入机制本身并不复杂，真正要守住的是客户端文件的读取边界。默认关闭权限、临时按需开启、双端交叉校验、目录独立隔离、操作结果留痕，做好这五件事，就能把原本图方便的导入命令，变成可审计的规范运维动作。