💡 場景假設
我們進行的是 頻繁批量導入、對數據持久性容忍較高 的場景，比如日志表、緩存表、臨時數據表等。如果系統崩潰可重導入，那我們就可以犧牲一點寫入安全性來換極致性能。
?? 參數配置推薦（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 導入而生的「性能爆發模式」，吞吐可提至原來的數倍甚至十倍，尤其適合日志類、可重導數據、臨時分析表等。
)
