delimiter 本身不影响 copy 性能，真正影响性能的是分隔符是否与数据冲突；若无冲突，制表符或竖线等简单分隔符比 csv 模式快 15%–30%，因后者需逐字符解析引号、转义和换行。
sql 的 COPY 命令中，DELIMITER 设置本身不直接影响导入性能，真正影响性能的是字段分隔符是否与数据内容冲突，进而决定是否需要转义、引号包裹和解析复杂度——而 CSV 格式（通常用逗号+双引号+换行）因语法较复杂，解析开销普遍高于简单分隔符（如 t 或 |）。
DELIMITER 选择对 COPY 性能的实际影响
postgresql 的 COPY 是流式二进制/文本解析，几乎不进行语法校验。只要分隔符在数据中**不出现**，无论设为逗号、制表符或竖线，性能差异可忽略。
- 安全前提：分隔符必须在整列数据中完全未出现（包括空格、换行、NULL 字节）
- 若强行用逗号作
DELIMITER但数据含未引号包裹的逗号（如地址字段"123 Main St, Apt 4B"），COPY会报错或错位，此时必须改用 CSV 模式或预处理数据 - 制表符（
E't'）或竖线（'|'）作为分隔符时，天然避开了常见文本内容，极少需引号/转义，解析路径最短
CSV 模式为何更慢？关键在解析逻辑
COPY ... format CSV 启用完整 CSV 解析器：需识别双引号包裹、内部引号转义（""）、跨行字段、CRLF/LF 行尾统一等。这些操作无法向量化，逐字符扫描且分支多。
- 即使所有字段都无引号、无换行，CSV 模式仍要检查每行首尾是否为双引号、扫描引号配对
- 对比：纯文本模式（
DELIMITER E't'）只需找第一个制表符位置，跳到下一字段，循环即可 - 实测中，同等数据量下，CSV 模式导入耗时常比
t分隔高 15%–30%，尤其在宽表（50+ 列）或含长文本字段时更明显
提升导入性能的实用建议
不必纠结“CSV 还是 DELIMITER”，而应根据数据特征选最低开销路径：
- 导出端可控时：用
psql copy或pg_dump --inserts配合DELIMITER E't'，禁用QUOTE和ESCAPE - 必须用 CSV（如从 excel 导出）：确保源数据已清理（无换行、无未引号逗号），再用
FORMAT CSV QUOTE '"' ESCAPE '"'，避免额外解析歧义 - 超大数据集（>1GB）：先用
iconv或sed将 CSV 转为t分隔（替换逗号为制表符，删引号），再用原生COPY文本模式导入 - 禁用索引与外键：导入前执行
SET CONSTRAINTS ALL DEFERRED，并临时DROP INDEX，导入完成后再重建
小结：性能瓶颈不在关键词，而在解析动作
DELIMITER 是个开关，CSV 是一套规则。快慢取决于你让数据库做多少事：跳分隔符很快，匹配引号很慢。数据干净就用简单分隔符；数据杂乱又不能清洗，才用 CSV 模式兜底——但要接受它天然更重。