PostgreSQL流式COPY导入需手动分批、显式事务控制（每批BEGIN/COMMIT），推荐5000–50000行/批，配合禁用索引、WAL调优等提升性能。
SQL 的 COPY FROM STDIN 是 PostgreSQL 中最快的数据导入方式之一，但默认行为是“全量提交”或依赖外部事务控制，容易导致内存溢出、锁表时间过长、失败后回滚代价高。要真正实现流式导入并合理控制事务大小，关键在于：**手动分批、显式事务管理、避免单一大事务，同时保持 COPY 的高效性**。
流式导入 ≠ 一次性读完再 COPY
所谓“流式”，是指不把全部数据加载进内存，而是边读边写、分段提交。PostgreSQL 的 COPY FROM STDIN 本身不提供内置分批能力，它只负责接收标准输入流中的数据行——所以流式控制必须由客户端代码（如 Python、Go、psql 脚本）实现：
- 从文件、管道或网络流中按行或按块（如每 10,000 行）读取数据
- 对每个批次单独发起一次
COPY FROM STDIN（在同一个数据库连接内） - 每个批次前后用
BEGIN/COMMIT包裹，形成独立小事务 - 避免使用
psql -c "COPY ... FROM STDIN"直接传大文件，那仍是单事务
事务大小需权衡吞吐与稳定性
批次太小（如每次 100 行）：事务开销占比高，整体导入变慢；批次太大（如 100 万行）：单次失败需重试大量数据，内存和 WAL 压力陡增。推荐起始值为 5,000–50,000 行/批，具体根据以下因素调整：
- 行宽：宽表（如含 JSONB、TEXT 字段）应减小批次，防止单批内存超限
-
服务器配置：
work_mem和max_wal_size影响单事务 WAL 生成与排序性能 - 业务容忍度：若要求“至多丢失 N 行”，N 就是最大批次大小
- 可配合
pg_stat_progress_copy视图监控实时进度，便于动态调优
Python 示例：带事务控制的流式 COPY
使用 psycopg2 时，不要用 cursor.copy_from() 一次性传整个文件对象。正确做法是分块读取 + 手动构造 COPY 流：
with open('data.csv') as f:
batch = []
for line in f:
batch.append(line)
if len(batch) >= 10000:
cursor.execute("BEGIN")
with io.StringIO(''.join(batch)) as buf:
cursor.copy_from(buf, 'my_table', sep=',', columns=cols)
cursor.execute("COMMIT")
batch.clear()
# 处理余下数据
if batch:
cursor.execute("BEGIN")
with io.StringIO(''.join(batch)) as buf:
cursor.copy_from(buf, 'my_table', sep=',', columns=cols)
cursor.execute("COMMIT")
注意：务必关闭自动提交（conn.autocommit = False），否则每个 copy_from 会隐式提交，失去事务控制能力。
其他实用优化点
-
禁用索引与约束：导入前
ALTER TABLE ... DISABLE TRIGGER ALL，导入后再重建，提速明显 -
调整 WAL 级别：临时设为
replica或minimal（仅限非复制环境），减少日志量 -
使用 UNLOGGED 表：若允许崩溃丢失数据，建表时加
UNLOGGED，COPY 速度可提升 2–3 倍 - 并行导入慎用：多连接并发 COPY 同一表会争抢锁，建议单连接分批 + 异步 I/O 提升吞吐，而非盲目加进程
