連線池：為什麼把池開大反而更慢

連線池存在的理由只有一個：建立連線太貴，貴到不能每次查詢都做一次。先看貴在哪。

一次「建立連線」實際發生的事

1. TCP 三次握手——一個 RTT（同機房約 0.5ms，跨區可能 30ms 以上）
2. TLS 握手（如果有加密）——再一到兩個 RTT，加上憑證驗證與金鑰交換的 CPU 成本
3. 資料庫認證——帳密驗證、權限載入
4. Session 初始化——設定字元集、時區、隔離等級、autocommit
5. 資料庫端配置資源——MySQL 為每個連線開一條 thread，PostgreSQL 直接 fork 一個 process

連線不只是「一個物件」

它同時佔用三邊的資源：

• 應用端：一個 socket、一個檔案描述符（fd）
• 網路中間層：防火牆、負載平衡器的連線追蹤表都有一筆
• 資料庫端：一條 thread 或 process，加上它的記憶體（PostgreSQL 每個 backend 幾 MB 起跳）

所以池做的事很單純

先建好一批連線放著，用完不關、還回池裡，下次直接拿。把「幾十毫秒的建立成本」攤平成「幾乎為零的借還成本」。

直覺是這樣的：連線越多 → 能同時處理的請求越多 → 吞吐越高。這個直覺在超過某個點之後就完全錯了。

關鍵：真正在幹活的不是連線，是資料庫的 CPU 和磁碟

連線只是一條通道。資料庫實際能同時執行的工作量，受限於：

• CPU 核心數——8 核就是同時只能真的跑 8 件事，其餘都在排隊
• 磁碟 I/O 通道——能同時發出多少個有效的 I/O 請求
• 鎖與 latch 競爭——連線越多，搶同一份資源的人就越多

超過瓶頸之後，多開連線會發生什麼

8 核的資料庫，100 個連線同時送查詢進來

→ 100 個 thread 搶 8 顆 CPU
→ 大量 context switch（每次切換都要換快取、換 TLB）
→ CPU 有相當比例花在「切換」而不是「幹活」
→ 鎖競爭同步放大：等鎖的人變多，持鎖時間也被拉長

結果：吞吐量下降，而且每個請求的延遲都變長

HikariCP 官方建議的起算公式

連線數 = (CPU 核心數 × 2) + 有效磁碟數

一台 8 核、用 SSD（視為 1）的資料庫，算出來是 17。這個數字通常讓人很不安——「才 17 個連線怎麼撐得住幾百 QPS？」

撐得住，因為連線是「借用」不是「佔有」

一個請求只在真正執行 SQL 的那幾毫秒持有連線，其餘時間（處理 HTTP、跑業務邏輯、序列化 JSON）都不需要連線。

排隊不是壞事。在池外面排 2ms，比擠進去讓所有人都慢 80ms 好得多——這是連線池設計的核心哲學。

Spring Boot 從 2.0 起預設用 HikariCP。它的參數不多，但每一個都對應一個具體問題。

maximumPoolSize —— 並行上限

spring.datasource.hikari.maximum-pool-size=10

池裡最多幾個連線。這是整個系統真正的資料庫並行上限，不是 Tomcat 的執行緒數。預設 10——不要因為「看起來太小」就調大，先看下一張卡的算法。

minimumIdle —— 保持待命的數量

閒置時至少留幾個連線不關掉，避免流量突然回來時要重新建立。HikariCP 官方建議不要設——不設的話它會等於 maximumPoolSize，變成固定大小的池。固定大小反而更好，因為「動態伸縮」在尖峰時剛好會讓你付出建立連線的成本。

connectionTimeout —— 等不到連線就放棄

spring.datasource.hikari.connection-timeout=3000   # 毫秒，預設 30000

池滿了、所有連線都被借走時，新的請求要等多久才放棄並丟 SQLTransientConnectionException。

maxLifetime —— 連線的最長壽命

spring.datasource.hikari.max-lifetime=1500000   # 毫秒，預設 1800000（30 分）

一個連線活過這麼久就會被主動汰換掉（在閒置時，不會打斷使用中的連線）。這個參數的重要性遠超它的名氣——下一張卡專門講它。

順帶一提：idleTimeout

閒置多久就關掉多餘的連線。只有在 minimumIdle 小於 maximumPoolSize 時才有作用；照上面的建議不設 minimumIdle 的話，這個參數等於不存在。

這是連線池最經典的靈異現象，而且它的成因完全不靈異。

徵狀

• 錯誤訊息是 Communications link failure、Connection reset、The last packet successfully received from the server was N milliseconds ago
• 通常出現在深夜或清晨等低流量時段
• 重試一次就成功了，所以很容易被當成「網路不穩」而忽略
• 白天尖峰時反而幾乎不出現

成因：有人在你不知道的時候切斷了連線

連線閒置太久時，路徑上有三個角色可能主動把它切掉：

1. 資料庫本身：MySQL 的 wait_timeout（預設 8 小時，但雲端服務常改成 5～30 分鐘）
2. 防火牆 / NAT 閘道：連線追蹤表有 idle timeout，常見 5～30 分鐘，而且經常是直接丟棄封包，兩端都不會收到 FIN
3. 負載平衡器 / Proxy：同樣有 idle timeout

解法：讓池比所有中間設備更早汰換連線

maxLifetime  <  min(資料庫 wait_timeout, 防火牆 idle timeout, LB idle timeout)

• HikariCP 官方建議：比最短的那個少幾秒（留出時間差，避免剛好在邊界上撞車）
• 例：資料庫 wait_timeout 是 600 秒 → maxLifetime 設 570000（570 秒）
• 先查清楚環境裡到底有哪些 timeout：SHOW VARIABLES LIKE 'wait_timeout'，以及去問網路/雲端設定

典型徵狀

• 服務剛啟動時完全正常
• 跑了幾小時或幾天之後，所有請求開始卡在等連線
• 最後大量 SQLTransientConnectionException: Connection is not available, request timed out after 30000ms
• 重啟服務就好了，過幾天又發生——這是最典型的指紋

真正的洩漏：借了沒還

// ❌ 例外路徑漏掉 close
Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(sql);
ps.execute();          // 這裡丟例外的話，下面兩行永遠不會執行
ps.close();
conn.close();

// ✅ try-with-resources
try (Connection conn = dataSource.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.execute();
}

用 Spring 的 @Transactional、JdbcTemplate、JPA Repository 幾乎不會洩漏——框架保證會還。會漏的幾乎都是手寫 dataSource.getConnection() 的地方。

診斷：打開洩漏偵測

spring.datasource.hikari.leak-detection-threshold=20000   # 毫秒

連線被借走超過這個時間還沒還，HikariCP 會印出當初借走它的那段 stack trace——直接指到兇手那一行。正式環境可以長期開著（20～60 秒），成本很低。

怎麼分辨是哪一種

一個請求要走完全程，會依序經過三個有上限的關卡。大多數線上事故都是因為這三個數字沒有對齊。

HTTP 請求
   ↓
① Tomcat 執行緒池      server.tomcat.threads.max     預設 200
   ↓
② HikariCP 連線池      maximum-pool-size             預設 10
   ↓
③ 資料庫連線上限        max_connections               MySQL 預設 151

觀念一：真正的並行上限是 ②，不是 ①

200 條 Tomcat 執行緒配 10 個連線，代表最多 190 條執行緒會同時在等連線。很多人看到這個數字會嚇到，覺得應該把池調大。

但這是正常且正確的設計。執行緒在等連線的時候幾乎不耗 CPU；讓它們排隊，總比全部擠進資料庫互相拖累好（回到第二張卡的推導）。

觀念二：③ 是全域的，要除以實例數

正確的算法

單一實例池大小 × 最大實例數  +  維運保留額  ≤  max_connections

例：max_connections = 151
    保留 20 給 DBA 連線、監控、備份工具
    最大實例數 = 6（含滾動更新時的新舊並存）
    → 單一實例池大小 ≤ (151 - 20) / 6 ≈ 21

要監控的指標

• hikaricp_connections_active——正在被借走的數量
• hikaricp_connections_pending——正在排隊等連線的執行緒數，這個持續大於 0 才是真的要調整
• hikaricp_connections_acquire_seconds——拿到連線花的時間

不要用「感覺」設池大小，也不要直接抄別人的設定。有兩個可以實際算的方法。

方法一：從流量反推（Little's Law）

需要的連線數 ＝ 目標 TPS × 每個請求持有連線的平均時間

關鍵是第二項——不是整個請求的耗時，只有真正在跑 SQL 的那一段。

假設：目標 500 TPS，每個請求平均跑 3 句 SQL、
      每句 5ms → 持有連線約 15ms

500 × 0.015 = 7.5  →  取 10（留一點餘裕）

方法二：從資料庫能力反推（HikariCP 公式）

連線數 ＝ (CPU 核心數 × 2) + 有效磁碟數

兩個算法取比較小的那個——因為兩邊都是上限，較小的那個才是真正的瓶頸。

實務調整流程

1. 從小開始（10 或算出來的值），不要從大開始往下調
2. 壓測或觀察正式流量，看 hikaricp_connections_pending
3. pending 持續大於 0 → 有人在排隊，可以考慮加
4. 每次加一點（例如 +5），同時看資料庫的 CPU 與平均查詢延遲
5. 如果加了池但吞吐沒上升、延遲反而變長 → 已經過了最佳點，退回去

不同用途要分開的池

如果同一個服務同時有「線上請求」和「後台批次」，應該用兩個 DataSource：

• 線上請求池：小、connectionTimeout 短，快速失敗
• 批次池：更小（2～3 個就夠）、timeout 長，允許慢慢跑

否則一個跑十分鐘的報表就能把線上請求的連線全部吃光。

連線池是一個很好用的調節閥，但它只能分配資料庫的處理能力，不能增加它。以下四種情況，動池是在治標。

1. 真正的瓶頸是 SQL 本身

一句沒走索引的查詢跑 5 秒（ch01），連線就被佔 5 秒。此時加大池只是讓更多請求同時慢，還會把資料庫 CPU 推更高。先去 EXPLAIN，不要先調池。

2. 交易邊界畫錯

@Transactional 包住第三方 API 呼叫（ch02），交易開多久連線就被佔多久。這種情況下池永遠不夠大——對方慢一點你就再爆一次。該修的是交易範圍。

3. 應用實例數量會大幅變動

Serverless、大量短生命週期的容器、每次擴容就多一組池——每個實例各自維護一個池的模型會直接壓垮資料庫。這時需要的是外部連線池：

• PostgreSQL：PgBouncer
• AWS RDS / Aurora：RDS Proxy
• 應用端的池可以設得很小，由外部 pooler 統一收斂到資料庫

4. 讀多寫少但全部打在主庫

該做的是讀寫分離（讀走 replica），配兩組 DataSource，而不是把單一池撐大。

一個反直覺的收尾

如果你的系統在池滿的時候優雅地排隊、快速失敗、然後自動恢復，那個池的大小很可能是對的。池的作用本來就包含「保護資料庫不被打死」——它擋住請求不是故障，是它正在做它的工作。