说句实话LOAD DATA LOCAL INFILE这条 MySQL 语句平时用好了是真省事一行命令几十万行数据就进去了可一旦中文乱码那真能让人怀疑人生。最近我在做一套业务历史数据迁移从线上库里导了一批 CSV打算用LOAD DATA LOCAL INFILE灌进新环境 MySQL结果导完一查用户的姓名和地址全成了各种奇奇怪怪的符号。折腾了半个多小时我顺手把同一个问题分别丢给了 DeepSeek、豆包、通义千问这三个 AI 助手想看看谁答复得最快、最准没想到三个模型给出的答案质量差异比我想象中要大得多。这篇文章不打算只给一个 SQL 模板就完事。我会先把LOAD DATA LOCAL INFILE中文乱码这个问题的病根拆开讲清楚再把我给三个模型出的五道测试题、评分标准、实测结果逐条放出来最后把我日常排查这类问题最常用的四套解决姿势完整摆出来。不管你是刚接触 MySQL 的 Python 后端开发还是经常跟数据导入打交道的 DBA都能从这里拿到可以直接抄作业的方案。1. 先得把病根说清LOAD DATA 中文乱码到底是谁的错很多人遇到中文乱码第一反应就是「MySQL 编码有问题」然后开始改数据库配置、改表结构折腾一大圈还是老样子。其实这个问题往往不是单点故障而是多个环节没对齐导致的。1.1 乱码不是 MySQL 单项问题而是字符集四方对齐一条LOAD DATA LOCAL INFILE语句从文件到最终写入表中间至少要经过四层字符集相关的环节数据文件本身的编码这个文件是 UTF-8 还是 GBK还是 UTF-8 with BOM甚至是 ANSI。客户端和服务器的连接字符集也就是character_set_client、character_set_connection这一串参数。目标表的字段字符集表结构里的CHARSET到底是utf8mb4还是gbk还是latin1。最后才是你看数据的终端显示编码比如 SSH 终端用的编码和数据库里实际存的不一致。你可以把这四层理解成四个传话筒。文件侧传出来的字节流是什么方言连接层用什么规则去听懂表结构愿意用什么编码收下终端又按什么规则展示出来。这四个环节里只要有任何一个对不上你看到的就是乱码。LOAD DATA LOCAL INFILE只是搬运工搬运过程本身不出错错的是搬运双方说的人话不一样。很多 AI 在回答这类问题时只会盯着「表结构要改 utf8mb4」或者「连接加 useUnicode」这种数据库侧补丁却忽略了数据文件本身的编码以及文件编码和CHARACTER SET子句之间的对应关系。这恰恰是实际工作中最常踩的坑。1.2 常见乱码长相和对应病因乱码不是只有一种长相不同长相代表了不同的病因这个要先学会分辨。乱码表现典型病因说明中文全部变成???目标字段不支持该字符或文件字节被按错误字符集解释常见于表是latin1、或者 MySQL 老版本里用了utf8存不下 4 字节字符出现锟斤拷这类字符UTF-8 字节被按 GBK 解码后再转存本质是编码解释错乱属于程序员圈著名的「编码事故」中文变成一堆中UTF-8 字节被单字节字符集比如 latin1解释后显示经常出现在连接字符集和目标终端不一致的时候第一列数据前面多了个?或看不见的字符CSV 文件带 UTF-8 BOMBOM 字节EF BB BF被当成列数据读进去了每行末尾都带\r或字段尾有奇怪空格Windows 下 CSV 是 CRLF 换行而语句写死了LINES TERMINATED BY \n\r被当成字段内容的一部分存了进去记住一个原则先看数据到底存成了什么字节再判断是哪个环节出的问题。不要凭肉眼看到的乱码字符瞎猜。1.3 最小复现案例我自己做测试一般用一个最简单的例子你也能快速复现。先准备一个/tmp/user.csv文件内容是 UTF-8 编码username,city 张三,北京 李四,上海建一张表CREATE TABLE user_info ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50), city VARCHAR(50) ) DEFAULT CHARSETutf8mb4;然后故意写一个「裸奔」的导入语句LOAD DATA LOCAL INFILE /tmp/user.csv INTO TABLE user_info FIELDS TERMINATED BY , LINES TERMINATED BY \n IGNORE 1 LINES (username, city);当服务器端的character_set_client是latin1、而文件又是 UTF-8 的时候这条语句大概率不会报错但导进去的中文就是乱码。因为 MySQL 在LOAD DATA时如果没写CHARACTER SET子句就会按连接字符集去解释文件字节连接层告诉它这是latin1它就拿 latin1 去解析 UTF-8 的中文字节后面再怎么存都是错的。问题来了文件是 UTF-8表是 utf8mb4为什么还会乱因为文件字节在到达表之前已经被连接层用错误字符集解读并转换过一次了。这就是我不厌其烦想强调的字符集问题一定是链路问题不是单点问题。2. 测评怎么做的问题设计、评分维度和参考答案要判断三个 AI 谁说得对不能只丢一句「中文乱码怎么办」然后看谁字数多。我把问题设计成五个递进层次从基础到进阶覆盖了实际工作中最常见的各个场景。2.1 五个递进问题Q1基础问法MySQL 里用LOAD DATA LOCAL INFILE导入 CSV中文写入后是乱码怎么解决Q2文件侧场景我有一个 CSV 文件是 GBK/ANSI 编码但目标表是 utf8mb4该怎么用LOAD DATA导入才不乱码Q3机制理解LOAD DATA和LOAD DATA LOCAL INFILE有什么区别MySQL 8.0 默认开启local_infile吗Q4类真实场景在 Windows 上用 Excel 另存的 CSV里面有中文还有 BOM 和回车符号怎么用LOAD DATA兼容Q5完整落地请给出一个包含CHARACTER SET、字段分隔符、行终止符、忽略表头等完整选项的LOAD DATA LOCAL INFILE示例 SQL。这五道题不是随便出的。Q1 是网上问得最多的Q2 是很多老项目导出的 GBK 文件的经典痛点Q3 考的是模型对机制的理解能区分「懂原理」和「背答案」Q4 是我实际踩过的 Excel 导出坑Q5 是看模型能不能输出一份可以直接复制使用的完整语句。2.2 评分维度我用了四个维度评分单项满分如下维度分值说明正确性40核心结论是否符合 MySQL 官方机制有没有明显错误或误导完整性25是否覆盖文件编码、连接字符集、表结构、终端四层链路实操性20给出的命令、参数、步骤能否直接照做还是空泛描述避坑提示15是否主动提到 BOM、CRLF、local_infile 开关、安全风险等细节合计100—2.3 参考答案要点这五个问题我自己先写了一版标准答案作为后续评分的锚点Q1 参考答案先确认文件实际编码再确认表是utf8mb4SQL 里加CHARACTER SET子句连接层保持SET NAMES utf8mb4最后查 HEX 确认存储结果。Q2 参考答案最直接的方法是 SQL 里写CHARACTER SET gbk让 MySQL 按 GBK 解析文件并把内容转成 utf8mb4 存储或者先把文件转成 UTF-8 再导入。Q3 参考答案LOCAL表示文件在客户端非LOCAL表示文件在服务器端MySQL 8.0 的local_infile默认是 OFF需要配置SET GLOBAL local_infile 1客户端连接时还要加--local-infile1。Q4 参考答案Excel 在中文 Windows 下另存的 CSV 常见 GBK 编码如果用 UTF-8 with BOM 保存BOM 会污染第一列换行符是 CRLF 时要用LINES TERMINATED BY \r\n最好先统一成 UTF-8 无 BOM 格式。Q5 参考答案完整 SQL 见后面 4.1 节重点就是CHARACTER SET必须放在FIELDS之前。评分就按这个标准来。如果模型只给了「改表结构」这一个方向正确性可以给一部分分完整性肯定拿不了高分。3. 三家模型逐题实测谁答对谁答漏以下是基于我最近一次实测的快照结论。要提前声明一句AI 模型会迭代同一个问题不同版本回答会有差异所以下面这些对比只代表我当时测试到的表现不代表某个产品永远如此。3.1 DeepSeek逻辑最完整基本给到标准答案DeepSeek 在五个问题上的表现最稳。Q1 它没有直接甩一段 SQL 了事而是先让我确认「文件本身是什么编码」这一步非常关键。它给的排查思路是先用file命令或编辑器确认文件编码再检查表结构字符集最后调整 SQL。这个顺序恰好对应了我前面说的「文件层 → 表结构层 → 语句层」的排查链路。Q2 它明确给出了CHARACTER SET gbk的写法并且解释了这个子句的作用是「让 MySQL 按 GBK 解析文件字节然后自动转换为表结构的 utf8mb4」这个解释相当清楚没有含糊。Q3 它准确说出了local_infile在 MySQL 8.0 默认 OFF、需要服务端和客户端同时打开还额外提了一句不要随便加载不可信来源的文件算是安全意识到位。Q4 它主动提到了 BOM 和\r\n换行这两个细节并且建议先用文本工具把文件转成 UTF-8 无 BOM 再导入。Q5 给出的完整 SQL 语法顺序正确CHARACTER SET放在FIELDS之前没有硬伤。整体评分我给了 93 分扣分点在于它对 Q4 场景中「Excel 另存为 utf-8 实际上是 utf-8 with BOM」这个反直觉陷阱强调得还不够。如果它能直接点出「在 Windows 上 Excel 另存的 UTF-8 CSV 前面会带 BOM需要专门去掉」这个场景下的答卷就能给满分。3.2 豆包入门够用细节有缺豆包的回答走的是「快速给方案」路线。Q1 中它给出了常见的三件套SET NAMES utf8mb4、表结构改utf8mb4、JDBC 连接加characterEncodingutf8。这三个点都对属于标准答案里的常见配置但如果文件本身是 GBK光这三件套是不够的。Q2 它提到「可以把 GBK 文件转成 UTF-8 再导入」这个建议方向正确但没给出CHARACTER SET gbk这种更直接的写法。Q3 它说LOCAL表示文件在客户端这个核心点是对的但对local_infile默认值没有展开说明只是泛泛提了一句「有些版本默认不开启」。Q4 它完全没提到 BOM只说了换行符这是比较明显的遗漏。Q5 给出的 SQL 语法基本正确但漏掉了IGNORE 1 LINES这种跳表头的实用选项。它的定位更像「新手科普」适合完全没接触过LOAD DATA的人快速了解有哪些方向但距离直接解决生产环境的问题还差一步。整体评分 72 分。3.3 千问中规中矩坑点提示较少通义千问的表现介于两者之间。Q1 给出的解决方向基本正确把「表结构用 utf8mb4」和「连接串加参数」都提到了但同样没有主动追问文件本身编码而是直接假设「你的文件是 UTF-8」这个假设在真实场景里很危险。Q2 它提到 GBK 文件需要处理但给出的方案更偏向「先转码再导入」没有提供CHARACTER SET gbk这个并列的可选路径算是答对了一半。Q3 它能准确说出LOCAL和普通LOAD DATA的区别也提到了local_infile开关但讲述比较简略。Q4 它提到 Windows 下 Excel 导出会有编码问题但没具体讲 BOM 怎么处理、CRLF 和 LF 的差异在哪。Q5 给出的 SQL 语法顺序基本正确不过没有对每个子句做解释。整体评分 78 分。能解决一部分问题但如果你照着它给的方向去处理一个 GBK 文件的真实导入大概率还得再查一轮资料。3.4 逐题对错汇总表问题DeepSeek豆包千问Q1 基础乱码对先查文件编码再给方案部分对给了三件套但没提文件编码部分对假设文件是 UTF-8 再给方案Q2 GBK 文件对直接给CHARACTER SET gbk部分对建议转码但没说可指定 gbk部分对倾向于转码路径Q3 LOCAL 机制对默认 OFF 说明到位对但偏浅没展开版本差异对简略但方向正确Q4 Excel/BOM/CRLF部分对提到 BOM 和换行没强调 Excel 假 UTF-8 陷阱部分对只提了换行没提 BOM部分对提了编码问题但没讲 BOMQ5 完整 SQL对语法完整且顺序正确对但漏了跳表头对语法正确但无逐项解释这个结果其实挺有意思三个模型在「大方向正确」的程度上都过关了真正的差距集中在「文件编码确认」和「BOM/CRLF 这些边角细节」上。而真实项目里把人逼疯的恰恰就是这些边角细节不是宏大的机制。4. 不抄答案也能修好四种可靠落地方案模型答得再好测试完最终还是要回到生产环境里把问题解决。下面这四种方案是我这几年实际处理中文导入乱码时最常用的按优先级排序。4.1 最简单LOAD DATA 里直接指定 CHARACTER SET最推荐的第一方案是在LOAD DATA语句里直接显式声明文件字符集让 MySQL 自己完成转换。比如文件是 UTF-8表是 utf8mb4LOAD DATA LOCAL INFILE /tmp/user.csv INTO TABLE user_info CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (username, city);如果文件是 GBK就把CHARACTER SET改成gbkLOAD DATA LOCAL INFILE C:/export/gbk_users.csv INTO TABLE user_info CHARACTER SET gbk FIELDS TERMINATED BY , LINES TERMINATED BY \r\n IGNORE 1 LINES (username, city);有一个语法坑必须单独拎出来说CHARACTER SET子句必须出现在INTO TABLE之后、FIELDS之前这是 MySQL 语法规定的位置。如果放在FIELDS后面或者放在语句末尾轻则语法错误重则被当作别的子句解析行为完全不可控。这个顺序问题恰恰是很多 AI 回答里偶尔会忽略的地方。4.2 文件侧标准化先把源头弄干净有时候你拿到的文件编码很乱甚至同一个目录下几个 CSV 的编码都不一样。与其在 SQL 上反复试不如先把文件批量转成 UTF-8 无 BOM。这一步在 Linux 下用iconv一行搞定iconv -f GBK -t UTF-8 gbk_users.csv utf8_users.csv先用file命令确认原始编码file -bi gbk_users.csv # 如果输出 charsetiso-8859-1 或 us-ascii别急着信中文环境下很多文件会被错误识别Windows 环境下的同学如果用 Notepad 打开文件发现右下角显示 ANSI那基本就是本机默认的 GBK/GB2312 编码另存为的时候记得选「UTF-8 无 BOM」。注意不要选「UTF-8-BOM」否则导入后第一行第一列会多出一个隐藏字符。Python 批量处理也很简单import pandas as pd df pd.read_csv(gbk_users.csv, encodinggbk) df.to_csv(utf8_users.csv, indexFalse, encodingutf-8)这个流程的价值在于文件侧干净了SQL 侧就不用为不同文件反复调整CHARACTER SET维护成本低很多。4.3 连接与会话侧兜底确保通道说同一种方言即使文件编码和表结构都正确连接层的字符集不对劲依然会产生问题。进入 MySQL 客户端前我一般会统一设置连接参数mysql --local-infile1 -uroot -p --default-character-setutf8mb4在会话里执行LOAD DATA之前也可以先手动设定SET NAMES utf8mb4; SET SESSION local_infile 1;如果是 Java JDBC 连接URL 里要带上字符集参数jdbc:mysql://localhost:3306/mydb?useUnicodetruecharacterEncodingutf8关于local_infile开关多说一句。MySQL 8.0 默认local_infile是关闭的如果你执行LOAD DATA LOCAL INFILE报错The used command is not allowed with this MySQL version去检查两处服务端的local_infile参数以及客户端启动时有没有加--local-infile1。有些云数据库默认不允许开启 LOCAL这种情况要么找运维开白名单要么改用非 LOCAL 方式把文件放到服务器端导入。4.4 排查命令全记录用 HEX 一击定位遇到乱码先别慌着反复改配置用HEX()函数看一眼数据到底存了什么是最快的定位方式SELECT id, username, HEX(username), city FROM user_info WHERE id 1;如果返回的HEX(username)是E5BCA0E4B889也就是「张三」两个字的 UTF-8 十六进制。那说明数据存得是对的乱码只出现在显示环节去调终端编码即可。如果返回的是3F3F说明存进去的就是两个问号问题出在写入环节应重点检查表字符集和文件编码。如果返回的是一长串E5BCA0E4B889C3A5...之类的混合字节说明文件字节被错误字符集解释且做了二次转换得从文件编码和连接字符集下手。检查文件本身还可以用hexdumphexdump -C /tmp/user.csv | head -5如果最前面出现ef bb bf说明文件带 BOM先用sed去掉sed -i 1s/^\xEF\xBB\xBF// /tmp/user.csv。5. 经验与使用建议让 AI 给出的答案真正能落地最后聊点关于「怎么用 AI 帮你解决技术问题」的个人体会因为这直接影响你拿到答案后的成功率。5.1 为什么 AI 容易漏掉文件编码这个前提从上面测评能看出来「文件编码」是几乎所有模型都会不同程度忽视的一环。原因倒不复杂大模型训练语料里关于LOAD DATA的讨论集中在 SQL 语句本身的参数上而「你的文件到底是 GBK 还是 UTF-8」这个问题非常依赖提问者提供的上下文模型没有从用户那里获得必要信息就只能默认文件是 UTF-8。所以在提问时不要只给一句「中文乱码怎么办」就指望得到万能答案。你要把场景信息主动喂给 AI是什么数据库、什么版本数据文件是什么编码你是怎么确认的目标表的字符集是什么乱码的具体表现是什么是全成问号还是变成乱码字符还是只有第一列有问题上下文越具体AI 给出的方案越能一步到位这个规律实测下来非常明显。5.2 我的提问模板和配套验证流程现在我遇到 MySQL 编码问题提问模板一般是这样的环境MySQL 8.0Linux 服务器客户端用 mysql CLI。 文件CSVfile 命令检测为 UTF-8带表头行尾是 LF。 现象执行 LOAD DATA LOCAL INFILE 后中文字段显示为问号已有表字段是 utf8mb4。 请给出排查步骤和可执行的 SQL。同时我会要求 AI 在给出方案后把验证手段也写出来请告诉我导入成功后如何用 HEX 函数确认数据没存错以及出错时不同 HEX 结果分别代表什么问题。这样拿到手的答案可以直接对照执行不需要再二轮追问。5.3 最后再分享一个小技巧三个模型我都用了不短的时间我的习惯是把同一个问题发给两个不同模型交叉比对然后都以「实测结果」为最终标准。像这次LOAD DATA乱码问题就算 AI 给了完全一样的 SQL我也一定会先在测试表上导入三行数据、查一次 HEX、确认无误后再导入全量。这个习惯帮我躲过了很多次生产事故。回到标题那个问题DeepSeek、豆包、千问谁对谁错我的回答是大方向都对细节决定成败。AI 能帮你少走弯路但「文件是什么编码」「终端用 UTF-8 还是 GBK 显示」「表结构存的是什么字节」这些事实AI 永远没法替你确认。把 AI 当成一个水平不错但偶尔粗心的同事该核实的还是得自己核实这才是用好这类工具的正确姿势。