Redshift已设VARCHAR(65535)仍报字符串超长错误，求解决方法

1. 字符集编码的字节数限制 #

VARCHAR(65535)的长度是按字节数计算，而非字符数。如果你的表使用UTF8mb4这类多字节编码，单个字符可能占用3-4字节，实际可存储的字符数会远低于65535（比如UTF8mb4下最多存约16383个字符）。

• 处理步骤：
  • 先检查表的字符集配置：SHOW CREATE TABLE your_table_name;
  • 若确认是多字节编码问题，要么将field_x改为TEXT类型（和VARCHAR(65535)字节上限一致，但存储逻辑更适配长文本），要么根据实际数据字节长度升级为MEDIUMTEXT（支持16MB）或LONGTEXT（支持4GB）。

2. CSV文件的字段解析异常 #

CSV中的field_x可能包含未转义的换行符、制表符，或导出时未正确处理的引号，导致COPY命令将多行内容误判为单个字段，实际长度远超预期。

• 处理步骤：
  • 用Notepad++等编辑器打开CSV，开启「显示所有字符」功能，检查字段内是否存在意外的换行、特殊字符。
  • 调整COPY命令的解析参数，明确分隔符、引号规则：

    COPY your_table_name FROM '/path/to/your/file.csv' WITH (FORMAT csv, DELIMITER ',', QUOTE '"', ESCAPE '\');
    

3. 数据库行总长度限制 #

部分数据库（如MySQL）对非TEXT/BLOB类型的行总字节数有65535的上限。即便field_x单独未超限制，加上其他字段的字节数后，总行长度可能触发阈值。

• 处理步骤：将field_x改为TEXT类型，TEXT字段内容存储在行外，不计入行总长度限制。

4. COPY命令的字段映射错误 #

若COPY时未指定字段顺序，可能出现CSV列与表字段错位，导致其他长字段被导入field_x中。

• 处理步骤：明确指定COPY的字段列表，确保对应关系正确：

  COPY your_table_name (col1, col2, field_x, ...) FROM '/path/to/your/file.csv' WITH (FORMAT csv);
  

内容的提问来源于stack exchange，提问作者finn871