最近在往 MySQL 里导入一张 1000 万行的 tb_sku表时，我算是彻底领教了 LOAD DATA这个工具的"脾气"。原本以为这是个能救命的神器，结果差点被它整崩溃。今天就把这次的血泪史总结一下，希望能帮大家避雷。
一、 所谓的"智能解析"，其实一点也不智能
首先最大的误区就是：千万别把 LOAD DATA当成智能解析工具。
我一开始天真地以为，CSV 里的 null字符串，MySQL 总会帮我转成 NULL吧？结果现实狠狠打了脸。在 tb_sku表中，status字段是 char(1)，但 CSV 里写的是 null。LOAD DATA根本不会做语义判断，它直接把 'n', 'u', 'l', 'l'往字段里塞，直接导致 Data too long for column 'status'的错误。
结论一 ：LOAD DATA只认 \N是 NULL，其他的 null、NULL统统是字符串。
二、 最隐蔽的坑：字段错位
这是我踩得最深的一个坑。报错永远指向 status字段，让我一度以为是 status的长度不够。但当我用 select * from tb_sku where id=9449\G;查看时才发现，真正的原因是字段错位。
因为 CSV 里有些字段（比如 spec）包含了逗号，或者因为 null字符串占用了额外空间，导致整个数据流的列顺序向后偏移。MySQL 并不会告诉你"第 10 列有问题"，而是等到最后一列 status发现装不下时，才抛出错误。
这就好比排队，前面的人多占了位置，最后一个人永远是被挤出去的那个。
三、 为什么还在用 LOAD DATA？
既然这么多坑，为什么不全用 INSERT？原因很简单：速度。
在导入 1000 万行数据时，LOAD DATA INFILE的速度至少是单条 INSERT的 10 倍以上。对于海量数据迁移，它是唯一现实的选择。它不是不好用，而是它设计的初衷就是"在已知数据完全干净的前提下，提供最高吞吐量的写入"。
四、 血的教训：五个必须的检查步骤
经过这次折腾，我总结了使用 LOAD DATA前必须做的 5 项数据清洗检查，缺一不可：
-
检查分隔符是否唯一 ：确保数据内容中不包含你使用的分隔符（如
,或|），否则必须用双引号包裹，或者更换分隔符。 -
检查列数一致性 ：用
awk扫一遍文件，确保所有行的列数都等于表字段数，剔除脏数据。 -
规范化 NULL 值 ：将所有的
null字符串替换为\N，或者在 SQL 中使用NULLIF()函数处理。 -
检查字段长度 ：特别是
varchar类型的字段，防止超长字符串导致写入失败。 -
检查换行符 ：如果是 Windows 环境下生成的文件，记得用
dos2unix处理，防止\r\n引发解析异常。
五、 总结
LOAD DATA是一把双刃剑。它锋利无比，能帮你快速切开海量数据；但它也很笨重，没有任何容错能力。
如果你指望它能像 Excel 一样智能纠错，那你一定会失望。但如果你愿意花几分钟做一次数据清洗，它绝对是 MySQL 生态中最值得信赖的批量导入工具。
我只是测试用的，所以在网上看了一遍文章，直接将它设为宽松模式：