luoer
(Ti D Ber M1kmcdis)
1
一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题
【TiDB 使用环境】测试环境
【TiDB 版本】v8.5.6
【部署方式】单机部署，1个TiKV实例
【操作系统/CPU 架构/芯片详情】AMD 92542/ openEuler-24.03-LTS SP3
【机器部署详情】3.84T SATA SSD2/32G*8/
【集群数据量】几百条
【集群节点数】1
【问题复现路径】导入csv文件数据
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
使用IMPORT INTO FROM 导入csv文件，出现2个问题：
1、csv文件大小2.0GiB，37万条记录，不加SPLIT_FILE重复导入几次都成功，耗时33-35秒。加SPLIT_FILE参数，成功的时候耗时9-11秒，出错的时候提示encode kv error in file **csv:268440832 at offset 268440832: syntax error: cannot have consecutive fields without separator。csv数据有少量变动，不同csv文件offset 有变化，但是都在256M上下变动。估计是按行截取的时候没有考虑换行符前面的反斜杠，导致不正确截断。
2、按前面导入37万记录耗时33-35秒计算，每秒可以导入1万条，但是在导入少量数据的小文件csv时，一般耗时都在2.7秒。csv文件57K，405条记录测试2次，一次1.83秒，一次2.7秒。
luoer
(Ti D Ber M1kmcdis)
4
未压缩，符合限制。使用LINES_TERMINATED_BY=‘\n’，有text字段其内容内容包含\n时出现此问题。
luoer
(Ti D Ber M1kmcdis)
5
假设有2行，一个字段，Row[0].content=“a
b
c”，包含了2个换行符，Row[1].content“abc”，导出到csv文件是：
“a\
b\
c”
“abc”
导出到csv文件是4行，有3个换行符，第1和第2个换行符是字段内容，不能视作行分割的换行符，但是被作为行分割符，把这个字段的内容分开了。问题在这里。
wbslxw
(Ti D Ber Cl S0j Eng)
6
一、问题 1：大文件加 SPLIT_FILE 参数随机报错
SPLIT_FILE 切分 CSV 文件时，是按固定字节大小（约 256MB）切分的，不会识别 CSV 的行边界和转义规则。
luoer
(Ti D Ber M1kmcdis)
9
单机单实例TIKV部署，未设置TiFlash副本，SATA SSD，这个检查也太耗时了吧。不知道卡在哪里。
luoer
(Ti D Ber M1kmcdis)
12
1、不管换什么样的换行符，字段内容包含这个“换行符”时，就会出错。
2、主库是MySQL5.7.44，每天凌晨同步到TiDB，使用TiDB的TiFlash满足文章搜索速度。舍弃SPLIT_FILE参数，运行一个星期了，内容正确。
3、可以不用质疑其他，单从逻辑分析，就知道原因了。简单的一个语句，文件大小2GiB，加SPLIT_FILE参数就导入失败，不加就导入正常。
WalterWj
(王军 - PingCAP)
13
好吧，那感觉是工具可以优化。
1、不管换什么样的换行符，字段内容包含这个“换行符”时，就会出错。
是这样的，但是你可以配置一个很生僻的。比如一些客户用 |@|
luoer
(Ti D Ber M1kmcdis)
14
配置的再生僻，一旦遇到了就是大问题，多花几十秒的时间算了，为了不出错，多花一点时间没关系。期待后续版本改进。
