登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  MySQL

MySQL LOAD DATA 导入含换行文本时如何配置字段包围符

来源:17golang原创

时间:2026-09-11 13:58:28 140浏览 收藏

LOAD DATA 导入 CSV 时,如果备注、描述或日志列本身包含真实换行,最容易出现的现象是:一条记录被读成两条,后续列全部错位。处理重点不是单独把换行符“转义”,而是让 MySQL 同时知道字段在哪里开始、在哪里结束,以及文件的一行实际由什么字符结束。

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

对于逗号分隔、文本字段用双引号包围的文件,通常使用 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"',再按文件实际格式设置 LINES TERMINATED BY '\n''\r\n'。包围符把换行纳入字段内容,行终止符只负责识别包围范围之外的记录边界。
要点速览
  • ENCLOSED BY 决定字段包围字符,含换行的字段必须有清晰的包围边界。
  • OPTIONALLY 主要影响输出格式;读取输入时,包围符本身仍会参与字段识别。
  • 文件来自 Windows、Linux 或导出工具时,先确认是 CRLF 还是 LF,再处理转义符和字符集。

字段包围符为什么能容纳换行内容

假设文件的两列是编号和备注,第二列允许多行文本:

1001,"第一行备注
第二行备注"
1002,"没有换行的备注"

这里的逗号是字段分隔符,双引号是字段包围符,第一条记录中的换行位于一对双引号之内。MySQL 的输入解析会把包围字段中的换行当作当前字段内容;只有遇到包围范围外的行终止符,才形成新的记录边界。

MySQL LOAD DATA 中 CSV 文件、逗号字段分隔符、双引号包围符、多行文本字段、LF 或 CRLF 行终止符和解析器的静态关系图
图1:字段包围符把多行文本保持在同一个字段边界内,分隔符和行终止符仍各自承担独立职责。

因此,单纯把 LINES TERMINATED BY 改成其他字符并不能解决问题;如果字段没有可靠的包围符,解析器仍无法判断某个换行属于字段内容还是新记录。

先对齐分隔符、包围符和换行符

一个适合上述文件的最小写法如下。示例假定文件使用 UTF-8、逗号分隔、双引号包围字段,并且每条记录以 Linux 风格 LF 结束:

LOAD DATA LOCAL INFILE '/data/notes.csv'
INTO TABLE import_notes
CHARACTER SET utf8mb4
-- 逗号只在包围字段之外承担列分隔职责
FIELDS TERMINATED BY ','
-- 双引号包住可能出现逗号或换行的文本列
OPTIONALLY ENCLOSED BY '"'
-- 保留默认反斜杠转义语义,除非生产方另有约定
ESCAPED BY '\\'
-- 文件若来自 Windows,应改成 '\\r\\n'
LINES TERMINATED BY '\\n';
参数解决的问题常见判断
FIELDS TERMINATED BY字段之间如何分列CSV 通常是逗号,制表文本通常是 \t
[OPTIONALLY] ENCLOSED BY哪些字符包住字段值常见是双引号,且必须是单个字符
ESCAPED BY引号、反斜杠等特殊字符如何表示先与导出方约定,不要盲改为空字符串
LINES TERMINATED BY包围字段之外的记录边界LF 与 CRLF 不要混淆

OPTIONALLY 不要理解成“输入时可有可无、因此可以不写”。在读取输入时,MySQL 仍会根据 ENCLOSED BY 判断字段边界;OPTIONALLY 对输入解释没有改变。它更容易在导出和回读场景中造成误解。

MySQL LOAD DATA 的 FIELDS 参数域、LINES 参数域、用户变量与目标表列之间的静态依赖关系图
图2:按 FIELDS、LINES 和目标映射三个边界查看参数,避免把列分隔符误当成行终止符。

引号和空值要按文件生产规则处理

字段值中如果还包含双引号,不能只看表面字符。MySQL 文档说明,包围符前有转义字符时会被当作字段内容;包围符也可以在输入中成对出现并还原为一个字符。生产方若采用反斜杠转义,就保留默认的 ESCAPED BY '\\';若明确采用 CSV 风格的成对双引号,应让导入规则与生成规则保持一致,别在没有样本的情况下随意把转义符设为空。

更稳妥的方式是先把原始字段接到用户变量,再做清洗。例如目标表有导入时间,而文件中只有编号和备注:

LOAD DATA LOCAL INFILE '/data/notes.csv'
INTO TABLE import_notes
CHARACTER SET utf8mb4
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
ESCAPED BY '\\'
LINES TERMINATED BY '\\n'
-- 先接住原始文本,避免直接把脏值写入最终列
(@raw_id, @raw_note)
-- 用 SET 统一空串与目标列转换规则
SET note_id = NULLIF(@raw_id, ''),
    note_text = @raw_note,
    imported_at = CURRENT_TIMESTAMP;

这里的 NULLIF 只把空字符串转换为 NULL,不会把含换行的备注截断。若文件使用 MySQL 约定的 \N 表示 NULL,还应把该规则与生产方的导出格式一起确认。

导入异常时先查这份边界清单

  • 每行都错位:检查 FIELDS TERMINATED BY 是否真的等于文件分隔符。
  • 含换行字段被拆开:确认文本是否从字段开头就有包围符,且包围符成对出现。
  • 最后一列多出回车:Windows 文件尝试 LINES TERMINATED BY '\r\n',不要只改字段分隔符。
  • 中文乱码:检查文件字符集与 CHARACTER SET utf8mb4,这与字段包围符是两件事。
  • 引号内容异常:对照导出方的转义方式,重点看双引号是否反斜杠转义或成对转义。

生产导入建议先落到临时表,抽查包含逗号、双引号和真实换行的样本,再把字段映射到正式表。只要字段包围规则、行终止符和转义规则来自同一份文件约定,LOAD DATA 就能把多行文本作为一个字段稳定读入。

相关问题

OPTIONALLY ENCLOSED BY 能否省略?

语法上可以省略 OPTIONALLY,但不能省略字段包围字符的设计。输入文件中存在带逗号或换行的文本时,明确写出包围符更容易核对规则。

文件是 CRLF 时只写 LINES TERMINATED BY '\n' 可以吗?

不建议凭经验处理。应以文件真实字节为准;若回车残留在最后一列,优先改为 '\r\n' 并重新抽样。

为什么把 ESCAPED BY 设为空后更容易错位?

因为字段里的包围符、行终止符或字段分隔符可能失去明确的转义方式,读取器会把本应属于值的字符当成结构边界。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>