💡 场景假设
我们进行的是 频繁批量导入、对数据持久性容忍较高 的场景，比如日志表、缓存表、临时数据表等。如果系统崩溃可重导入，那我们就可以牺牲一点写入安全性来换极致性能。
⚙️ 参数配置推荐（postgresql.conf）
| 参数 | 推荐值 | 作用 |
|---|---|---|
synchronous_commit | off | 提交不等待 WAL 写入磁盘，大幅提升写入速度 |
wal_writer_delay | 200ms~500ms | 延迟 WAL 写入，合并更多日志减少磁盘 I/O |
commit_delay | 10000（10ms） | 提交前延迟，让多个事务聚合一起写入 WAL |
checkpoint_timeout | 30min | 延长检查点周期，降低频繁 checkpoint 造成的写入峰值 |
wal_compression | on | 压缩 full-page WAL，提高磁盘使用率和复制效率 |
checkpoint_completion_target | 0.9 | 检查点更平滑进行，避免 I/O 峰值 |
max_wal_size | 2GB 或更高 | 减少 checkpoint 触发频率（建议视导入总量调整） |
maintenance_work_mem | 512MB 或更高 | COPY 导入涉及排序/索引构建时提供更多内存 |
📌 修改
postgresql.conf后记得SELECT pg_reload_conf();或重启服务以生效。Powered by Moshow郑锴@zhengkai.blog.csdn.net
✅ 导入前的会话级配置（可写入导入脚本）
SET synchronous_commit TO OFF;
SET maintenance_work_mem TO '512MB';
🛠 COPY 导入最佳实践
事务包裹多个 COPY 操作：减少 commit 次数
禁用约束 & 索引再导入：避免额外开销
避免触发器 & 复杂表达式：纯数据搬运最快
批次大小控制：比如 10,000 行一批，比单行更高效
导入后手动
CHECKPOINT：确保 WAL 落盘恢复能力
🧠 总结一句话
这套配置是为 COPY 导入而生的「性能爆发模式」，吞吐可提至原来的数倍甚至十倍，尤其适合日志类、可重导数据、临时分析表等。
)
