copy FROM STDIN 比 INSERT 快因绕过sql解析和触发器，但常受WAL写入、检查点阻塞、内存不足制约；需调优wal_level、checkpoint_timeout、max_wal_size，启用synchronous_commit=off（可选），优先用format binary、FREEZE、禁用HEADER和LOG ERRORS，并优化客户端批量大小与索引策略。
为什么 COPY FROM STDIN 比 INSERT 快但实际没达到预期？
COPY FROM STDIN 的底层绕过了 SQL 解析和触发器，直接写入存储层，理论吞吐极高。但真实场景中常卡在 WAL 写入、检查点阻塞或内存不足上。关键不是“用没用 COPY”，而是“是否让 postgresql 把 COPY 的通道真正跑满”。
- 默认
wal_level = replica足够，但若启用了逻辑复制，需确认未意外升为logical（额外开销） -
checkpoint_timeout设得太小（如 30s）会导致频繁 checkpoint，严重拖慢 COPY；建议调大到 30min～1h - 确保
max_wal_size≥ 2× 单次 COPY 总数据量（按 WAL 日志体积估算，通常为原始数据的 1.2–1.5 倍） - 临时关闭
synchronous_commit = off可大幅提升速度，但仅限单次导入且可接受崩溃丢失最后几秒数据的场景
COPY 命令里哪些参数真正影响吞吐？
很多人只关注 DELIMITER 和 NULL，却忽略几个隐性瓶颈参数：
-
FORMAT binary比text或csv快 2–3 倍，但要求客户端能生成二进制格式（如psycopg2的copy_expert()+Binary()包装） -
FREEZE在目标表无其他并发写入时启用，跳过后续 VACUUM，减少 MVCC 开销；但仅对新插入的整个数据集有效 - 避免
HEADER（即使有 header 行），它强制 PostgreSQL 多做一次行解析；预处理数据时删掉 header 更稳 - 不加
LOG ERRORS—— 错误日志本身会成为 I/O 瓶颈；先用小批量验证格式，再全量跑
客户端侧最容易被忽视的性能断点
服务端调优到位，但客户端发数据太慢或太碎，照样卡在 socket buffer 或 python GIL 上：
- 使用
copy_from()（psycopg2）比copy_expert()更高效，因前者直接喂入文件对象或迭代器，避免字符串拼接 - 每批次提交 10k–50k 行；小于 1k 行会因网络往返放大延迟，大于 100k 可能触发客户端内存暴涨或超时
- 禁用客户端自动 commit（如 psycopg2 中设
autocommit=False），COPY 本身是原子操作，无需外层事务包裹 - 若用 Python，避免用
StringIO拼接 CSV —— 改用csv.writer直接写入BytesIO，减少编码转换
导入后必须做的三件事，否则前面全白调
COPY 不触发 ANALYZE，也不更新 pg_class.reltuples，统计信息滞后会让后续查询走错执行计划：
- 立即执行
ANALYZE table_name，别等 autovacuum —— 它默认延迟 1min+ 且可能被其他任务挤占 - 检查
pg_stat_progress_copy视图确认是否真完成（某些驱动异常中断时 COPY 可能静默失败） - 若表有索引，考虑先
DROP INDEX，COPY 完再CREATE INDEX CONCURRENTLY；否则索引维护会吃掉 40%+ 时间
最常漏的是索引重建顺序和 ANALYZE 延迟——看起来导入成功了，但下一条 JOIN 查询就慢 10 倍，问题根源其实在这里。