load data local infile 不支持中文路径怎么办

Question

在使用 MySQL 的 `LOAD DATA LOCAL INFILE` 语句时，若文件路径包含中文字符，常出现“文件未找到”或语法错误，导致数据导入失败。该问题主要源于客户端与操作系统对中文路径的编码处理不一致，尤其在 Windows 系统下更为常见。即使文件真实存在，MySQL 客户端（如命令行或某些工具）可能无法正确解析 UTF-8 或 GBK 编码的路径。解决方法包括：将文件移至无中文的纯英文路径、使用 MySQL Workbench 等支持编码转换的工具，或通过程序先读取文件再批量插入。根本规避方式是避免使用含中文的路径。

Answer 1

MySQL LOAD DATA LOCAL INFILE 中文路径问题深度解析

1. 问题现象与初步诊断

在使用 LOAD DATA LOCAL INFILE 语句时，若文件路径包含中文字符（如：C:\数据\导入.csv），即使文件真实存在，MySQL 客户端常报错：

ERROR 29 (HY000): File 'C:\数据\导入.csv' not found (Errcode: 2 - No such file or directory)

该错误并非文件缺失，而是客户端与操作系统之间对路径字符串的编码处理不一致所致。尤其在 Windows 系统中，系统默认使用 GBK 编码存储路径名，而 MySQL 命令行客户端通常以 UTF-8 解析输入，导致路径解码失败。

• 常见于命令行工具（mysql.exe）或部分 JDBC 驱动场景
• GUI 工具如 MySQL Workbench 通常内部做了编码转换，表现更稳定
• Linux 系统相对较少出现，因其文件系统普遍采用 UTF-8 编码

2. 根本原因分析：编码层冲突机制

深入底层，该问题涉及三层编码交互：

层级	编码标准	说明
操作系统文件系统	Windows: GBK / CP936 Linux: UTF-8	决定路径在磁盘上的实际存储形式
MySQL 客户端	UTF-8（默认）	mysql CLI 或驱动程序读取 SQL 语句时使用的字符集
通信协议	依赖连接字符集	客户端与服务端之间的字符编码协商结果

当用户输入中文路径时，若客户端未正确声明字符集，操作系统返回的 GBK 路径被当作 UTF-8 解析，产生乱码，最终导致“文件未找到”。

3. 解决方案矩阵：从规避到工程化应对

以下是五类典型解决方案，按实施成本和稳定性排序：

1. 路径规范化（推荐）：将源文件移至纯英文路径，如 C:\temp\data.csv
2. 使用图形化工具：MySQL Workbench、Navicat 等自动处理编码转换
3. 程序层代理导入：通过 Python/Java 读取文件后执行批量 INSERT
4. 设置客户端字符集：启动 mysql 客户端时指定 --default-character-set=gbk
5. Base64 编码传输：将文件内容编码后通过程序注入，绕过路径依赖

4. 实践案例：Python 批量导入替代方案

以下为使用 Python + PyMySQL 实现的替代方案，完全规避路径编码问题：

import pymysql
import pandas as pd

# 读取含中文路径的 CSV 文件（Python 支持自动编码探测）
df = pd.read_csv(r'C:\数据\导入.csv', encoding='utf-8')

connection = pymysql.connect(
    host='localhost',
    user='root',
    password='password',
    database='testdb',
    charset='utf8mb4'
)

with connection.cursor() as cursor:
    # 构建批量插入语句
    sql = "INSERT INTO users (name, age) VALUES (%s, %s)"
    data = [(row['name'], row['age']) for _, row in df.iterrows()]
    cursor.executemany(sql, data)
connection.commit()
connection.close()

5. 架构级规避策略与流程图

在企业级数据管道中，应设计标准化的数据接入流程，避免临时路径依赖。如下 Mermaid 流程图展示推荐架构：

graph TD
    A[原始数据文件] --> B{路径是否含非ASCII?}
    B -- 是 --> C[移动至标准化英文目录]
    B -- 否 --> D[直接处理]
    C --> E[生成元数据记录]
    D --> E
    E --> F[调用ETL脚本导入]
    F --> G[MySQL LOAD DATA INFILE]
    G --> H[验证导入结果]
    H --> I[归档并清理临时文件]

该流程确保所有数据入口路径均为 ASCII 兼容，从根本上消除编码歧义。