結論先講
怎麼寫比用什麼 DB 影響更大。 Bulk Insert vs 逐筆寫入差 26 倍，Connection Pool 調整差 70%，加 Redis Cache 差 650%——這些都是「寫法」和「配置」的差異。相比之下，PG vs MySQL 的差距在大部分場景只有 2-3 倍，而且各有強項互有勝負。你應該先把查詢寫對、配置調好，最後才考慮換資料庫。
數據總整理
PG vs MySQL：各有勝負
| 場景 | 贏家 | 差距 | 篇章 |
|---|---|---|---|
| JSON 查詢（JSONB） | PostgreSQL | 3.2 倍 | [[micro-service/17-db-pg-vs-mysql|#17]] |
| 寫入密集 | MySQL | 2.5 倍 | [[micro-service/17-db-pg-vs-mysql|#17]] |
| 全文搜尋 | PostgreSQL | pg_trgm 開箱即用 | [[micro-service/17-db-pg-vs-mysql|#17]] |
| 簡單讀取 | 持平 | < 10% | [[micro-service/17-db-pg-vs-mysql|#17]] |
結論：PG 是通用首選（JSON + 搜尋 + 擴充功能），MySQL 在純寫入密集場景有優勢。大部分專案用 PG 就對了。
查詢方式的影響（比選 DB 更大）
| 優化 | 效果 | 成本 | 篇章 |
|---|---|---|---|
| Bulk Insert vs 逐筆 | +2600%（26 倍） | 改幾行 code | [[micro-service/18-db-bulk-and-index|#18]] |
| 加 Index | +300~500% | 加 migration | [[micro-service/18-db-bulk-and-index|#18]] |
| Connection Pool 5→50 | +70% | 改一行配置 | [[micro-service/19-db-pool-and-infra|#19]] |
| ORM vs Raw SQL | < 10% | — | [[micro-service/18-db-bulk-and-index|#18]] |
注意 ORM vs Raw SQL 那一行：差距不到 10%。這表示用 ORM 不會讓你的系統變慢。效能問題幾乎都出在「沒加 index」「沒用 bulk」「pool 太小」，不是出在 ORM 本身。
進階儲存方案
| 方案 | 效果 | 適用場景 | 篇章 |
|---|---|---|---|
| MongoDB 讀取 | PG JSONB 只差 4% | 非結構化文件 | [[micro-service/19-db-pool-and-infra|#31]] |
| MongoDB 寫入 | 比 PG 快 8.6 倍 | 高速 log / IoT | [[micro-service/19-db-pool-and-infra|#31]] |
| Redis Cache（讀多） | +650% | 讀寫比 > 10:1 | [[micro-service/32-pg-migration-guide|#32]] |
| 讀寫分離 | +30% | 讀寫比 > 5:1 | [[micro-service/61-db-read-write-splitting|#61]] |
Redis +650% vs 讀寫分離 +30%——這個對比說明了一切。很多人一聽到「DB 太慢」就想做讀寫分離，但加 Redis cache 的效果是它的 20 倍，而且實作更簡單。
優化優先順序（這是這篇最重要的部分）
優先順序 1：Connection Pool 調整 → +70%（改一行配置，5 分鐘搞定）
↓
優先順序 2：加 Index → +300~500%（跑個 migration）
↓
優先順序 3：Bulk Insert → +2600%（改幾行程式碼）
↓
優先順序 4：Redis Cache → +650%（加 Redis 服務 + 幾行 code）
↓
優先順序 5：讀寫分離 → +30%（最後才做！）
為什麼讀寫分離排最後？
- 效果最小：+30% 在所有方案中排最末
- 成本最高：需要 Replica、路由邏輯、資料一致性處理
- 有副作用：Replica lag 導致「剛寫入的資料讀不到」問題
- 前提條件：前四項都做完後才可能需要它
讀寫分離不是壞方案，它只是 ROI 最低的方案。在 [[micro-service/61-db-read-write-splitting|#61]] 中我們實測了它的效果——確實有用，但你得確定前面四個更便宜的方案都已經做完了。
選型建議
什麼時候用 PG
- 大部分情況——它是通用最佳選擇
- 需要 JSONB 半結構化查詢
- 需要
pg_trgm全文搜尋（不想裝 ES） - 需要地理空間查詢（PostGIS）
- 資料完整性要求高（金融、醫療）
什麼時候用 MySQL
- 團隊已經很熟 MySQL 生態
- 寫入密集場景（IoT 資料收集、高頻 log）
- 已有大量 MySQL 遷移成本太高
什麼時候加 MongoDB
- 文件結構頻繁變動、沒有固定 schema
- 寫入量極大且不需要事務（8.6 倍寫入優勢）
- 不要用來取代 PG——JSONB 讀取只差 4%，PG 同時有關聯式查詢能力
什麼時候加 Redis
- 讀寫比超過 10:1
- 有明確的熱資料（首頁、排行榜、session）
- 需要計數器、rate limiting、分散式鎖
回到數據
所有結論基於以下壓測：
- [[micro-service/17-db-pg-vs-mysql|#17 PG vs MySQL]]——兩大 RDBMS 正面對決
- [[micro-service/18-db-bulk-and-index|#18 Bulk Insert 與 Index]]——查詢方式的巨大影響
- [[micro-service/19-db-pool-and-infra|#19 Connection Pool]]——最容易被忽略的配置
- [[micro-service/19-db-pool-and-infra|#31 MongoDB Benchmark]]——NoSQL 的定位
- [[micro-service/32-pg-migration-guide|#32 PG 遷移指南]]——從其他 DB 搬過來
- [[micro-service/61-db-read-write-splitting|#61 讀寫分離]]——最後的手段
調好配置和查詢方式之後，大部分系統根本不需要換資料庫。
下一篇
Storage 結論：什麼時候加什麼儲存服務 — DB 選好了，接下來看什麼時候需要加 Redis、ES、Kafka。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：B2E 結論：後端框架最終推薦與場景對照 → 下一篇：Storage 結論：什麼時候加什麼儲存服務