MySQL LOAD DATA 导入 TSV 时如何处理字段内制表符

MySQL 导入 TSV 时，字段内部如果有制表符，不能只把 FIELDS TERMINATED BY 写成 '\t' 就结束。真正要先判断文件如何表达这个字符：如果字段被双引号包住，用 ENCLOSED BY '"' 让引号内的制表符留在字段里；如果文件把它写成反斜杠加 t，则保留 FIELDS ESCAPED BY '\\' 让 MySQL 解码。未加引号的字段里若直接混入真实制表符，解析器无法知道它是内容还是下一列的开始，应该先改造文件格式。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/load-data.html

下面用一个包含编号、姓名和备注的导入场景说明判断方法、两种写法以及结果验证。示例中的图片是结构示意，不是本机执行截图。

先看清 TSV 的真实字节和换行方式

TSV 的字段分隔符通常就是一个真实的制表符，但“字段值里也有制表符”需要额外的边界信息。常见文件有两种可解析表达：

这里的 只是为了阅读而写的标记，真实文件中应是一个制表符。若第三列直接放入实际制表符，却没有引号或转义，MySQL 会把它当成新的字段分隔符，后面的列自然全部右移。

# l 模式会把不可见控制字符显示出来，先确认文件不是“看起来像 TSV”
sed -n '1,3l' contacts.tsv

# 十六进制输出用于区分真实 09 字节和反斜杠、字母 t 两个字节
xxd -g 1 -l 160 contacts.tsv

sed -n 'l' 输出中出现 \t，只说明终端用转义形式显示了制表符；还要结合十六进制结果判断字段内部到底是 09，还是 5c 74。同时确认换行是 LF 还是 CRLF，Windows 文件常需要把行结束符写成 \r\n。

用 ENCLOSED BY 保护引号字段内的制表符

如果导出端能把包含制表符的字段包在双引号里，优先使用这种格式。字段分隔符仍然是制表符，但引号中的实际制表符属于当前字段，不会结束该字段。

-- 目标表只保留与示例对应的三列，备注允许出现制表符
CREATE TABLE import_contacts (
    external_id BIGINT NOT NULL,
    person_name VARCHAR(100) NOT NULL,
    note TEXT NOT NULL
);

-- 双引号包住字段值，反斜杠继续负责识别转义字符
LOAD DATA LOCAL INFILE '/data/contacts.tsv'
INTO TABLE import_contacts
CHARACTER SET utf8mb4
FIELDS TERMINATED BY '\t'
       ENCLOSED BY '"'
       ESCAPED BY '\\'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(external_id, person_name, note);

例如第三列是 "仓库A夜班"，导入后 note 仍是一列，值中保留一个制表符。若引号本身也可能出现在备注中，要让上游按照同一套转义规则输出；不要一边让上游使用双引号加倍，一边又在 MySQL 中随意改成空的 ESCAPED BY。

用 ESCAPED BY 读取无引号字段的转义制表符

有些导出程序不会加引号，而是把字段内制表符写成两个字符 \t。这时字段之间仍用真实制表符分隔，字段值里的反斜杠加 t 由 MySQL 按转义规则解码。

-- @note 先接收原始字段，再统一写入目标列，便于扩展清洗规则
LOAD DATA LOCAL INFILE '/data/contacts-escaped.tsv'
INTO TABLE import_contacts
CHARACTER SET utf8mb4
FIELDS TERMINATED BY '\t'
       ESCAPED BY '\\'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(@external_id, @person_name, @note)
SET external_id = NULLIF(@external_id, ''),
    person_name = NULLIF(@person_name, ''),
    note = @note;

-- 导入后用 CHAR(9) 判断值中是否真的还原出制表符
SELECT external_id, person_name,
       LOCATE(CHAR(9), note) > 0 AS has_inner_tab
FROM import_contacts
ORDER BY external_id;

这个写法只适用于文件中的字段内制表符确实写成 \t。如果导出文件在未加引号的字段里直接写入真实 09，MySQL 无法把它和字段分隔符区分开；此时应该让上游改为引号包裹、反斜杠转义，或改用不会出现在内容中的字段分隔符。把 ESCAPED BY 设为空并不能恢复这类边界，反而会让特殊字符更难解释。

用 HEX、CHAR_LENGTH 和 SHOW WARNINGS 验证结果

导入没有报错，不代表字段没有错位。至少检查目标列里是否出现十六进制 09，并把行数、警告和换行残留一起看。

-- 09 代表制表符；HEX 能避免客户端把不可见字符显示成空白
SELECT external_id,
       CHAR_LENGTH(note) AS note_chars,
       LOCATE(CHAR(9), note) AS tab_position,
       HEX(note) AS note_hex
FROM import_contacts
ORDER BY external_id;

-- LOAD DATA 后立即查看本次语句产生的告警
SHOW WARNINGS;

-- 检查是否留下 Windows 行尾的回车字符
SELECT COUNT(*) AS trailing_cr_rows
FROM import_contacts
WHERE RIGHT(note, 1) = CHAR(13);

判断结果时可以按下面的顺序处理：

• tab_position > 0 且 note_hex 中出现 09：字段内制表符已经进入备注列。
• 备注被拆成多列或出现“列数不足”类告警：优先回到原文件确认是否把真实制表符放进了未加引号字段。
• 末尾出现 0D：把 LINES TERMINATED BY 调整为 '\r\n'，或先统一文件换行。

生产导入建议保留原始文件、记录使用过的 FIELDS 和 LINES 选项，并在正式写入前抽样检查一行带内部制表符的数据。这样即使字符集、换行或上游导出器发生变化，也能从原始字节重新判断，而不是只凭“导入成功”四个字排查。

常见问题

字段内是实际制表符时，能不能只修改 FIELDS TERMINATED BY？

不能。该选项定义的就是字段分隔符；未加引号或转义的实际制表符会被当作新字段。必须让文件提供引号或转义边界。

为什么把 ESCAPED BY 设置为空后反而导入错位？

空转义字符会关闭特殊字符的解码，文件中的 \t 不再还原为制表符；同时包含分隔符、引号或换行的值更难被安全解析。

怎么确认备注里的制表符不是普通空格？

使用 LOCATE(CHAR(9), note) 和 HEX(note)，不要依赖客户端的视觉显示。十六进制中的 09 才是制表符字节。