Connection pool 的核心概念是「重用並限制到下游服務的連線」。資料庫、Redis、broker 與 HTTP client 都可能使用連線池；連線池決定同時有多少工作能進入下游。 可先對照 Consumer Capacity。

應用程式多半不直接跟池要連線，而是透過 ORM 這一層——一段程式碼實際佔用哪一條、佔多久，由框架的作用域決定而不由那幾行決定。

概念位置

連線池是 application 並發與下游容量的閘門。Pool 太小會讓 request 等待；pool 太大會把壓力轉移到資料庫或外部服務，造成 timeout、排隊與資源耗盡。 可先對照 Consumer Capacity。

可觀察訊號與例子

系統需要檢查 connection pool 的訊號是 latency 升高但 CPU 不高，或高峰時大量 request 等待資料庫。活動期間 checkout 變慢，可能是 database pool 已滿，也可能是資料庫本身查詢變慢。

判定為 pool 已滿之後，下一個問題是誰佔住了連線，而這個問題的答案通常不是報錯最多的那個端點——多數 pool 實作記得下每條連線目前被哪個執行緒或請求借走（checkout owner），那份紀錄才是權威答案。歸因順序見 配額耗盡的症狀落在申請最頻繁的元件、成因在持有最久的那個。

設計責任

Pool 設定要搭配 timeout、查詢耗時、instance 數量與下游最大連線數。全部實例的池上限加起來要小於資料庫的 max_connections 扣掉維運保留的連線；一個 instance 跑多個 worker 程序時要乘上 worker 數，PHP-FPM 這類沒有程序內池的執行模型另有算法，見 1.17 應用程式存取資料庫的工具分層〈各語言執行模型下的連線模型〉。Runbook 應能看到 pool in-use、idle、wait count、timeout 與下游 error rate；in-use 一直貼著上限而查詢本身不慢，先查程式有沒有借了連線不還（見 Connection Leak）。