TiDB 中 Lightning 与 IMPORT INTO 导入二进制数据的差异分析

概述

在 TiDB 数据库使用过程中，用户可能会遇到使用 Lightning 工具和 IMPORT INTO 语句导入相同 CSV 数据时结果不一致的情况。本文将以一个实际案例为基础，深入分析这种差异产生的原因，并给出解决方案。

问题现象

用户在使用 TiDB 时发现，当导入包含二进制数据的 CSV 文件时，Lightning 工具可以成功导入，而使用 IMPORT INTO 语句则会报错"Data Too Long"。具体表现为：

1. 表结构包含 varbinary 和 binary 类型的字段
2. CSV 文件中使用 \x 前缀表示二进制数据（如 \x3148594b...）
3. Lightning 导入成功
4. IMPORT INTO 报错字段长度不匹配

技术背景

二进制数据表示

在 MySQL/TiDB 中，二进制数据可以通过以下方式表示：

• 使用 UNHEX() 函数转换十六进制字符串
• 直接使用二进制字面量（需正确转义）

导入工具差异

TiDB 提供了多种数据导入方式：

1. Lightning：物理导入工具，直接处理底层存储
2. IMPORT INTO：逻辑导入语句，通过 SQL 接口执行

问题原因分析

CSV 转义序列处理

关键差异在于两种工具对 CSV 文件中 \x 转义序列的处理方式不同：

1. IMPORT INTO 严格遵循 MySQL 的 LOAD DATA 语法规范，仅支持有限的转义序列：

   • \0 (NUL)
   • \b (退格)
   • \n (换行)
   • \r (回车)
   • \t (制表符)
   • \Z (Control+Z)
   • \N (NULL)

   \x 不是标准支持的转义序列，因此 IMPORT INTO 会将其视为普通字符，导致二进制数据长度计算错误。

2. Lightning 由于默认使用较宽松的 SQL_MODE，能够容忍这种非标准表示法，但实际导入的数据可能不符合预期。

正确的二进制数据导入方式

通过 INSERT 语句验证，正确的二进制数据导入应该：

• 对于 binary/varbinary 字段，使用 UNHEX() 函数处理十六进制字符串
• 或者使用标准支持的转义序列

解决方案

方案一：预处理 CSV 文件

1. 将 \x 前缀替换为标准的十六进制表示
2. 或者使用 UNHEX() 函数包裹二进制数据字段

方案二：调整 IMPORT INTO 的 SQL_MODE

执行 IMPORT INTO 前，可以设置会话级别的 SQL_MODE 与 Lightning 保持一致：

SET SESSION sql_mode = 'ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER';

方案三：使用程序转换

开发预处理程序，将二进制数据转换为：

• 标准十六进制字符串（不带 \x 前缀）
• 或者使用 BASE64 编码

最佳实践建议

1. 对于二进制数据导入，建议：

   • 使用标准十六进制表示（不带 \x 前缀）
   • 或者使用 UNHEX() 函数明确转换

2. 在开发测试阶段：

   • 先使用小批量数据验证导入结果
   • 检查实际导入的二进制值是否符合预期

3. 生产环境导入前：

   • 统一导入工具的使用规范
   • 对数据进行充分的预处理和验证

总结

TiDB 的不同导入工具对数据格式有着不同的处理方式，特别是在处理二进制数据时。理解这些差异有助于避免数据导入问题，确保数据完整性和一致性。建议用户根据实际需求选择合适的导入方式，并遵循标准的数据表示规范。