MySQL 一個連線一個執行緒，PG 一個連線一個進程
作者把這一條標成「最容易踩的雷」——系統擴展時最大的瓶頸差異，而它和查詢效能完全無關。
| 連線模型 | 特性 | |
|---|---|---|
| MySQL | 多執行緒（一個連線 ＝ 一個 Thread） | 切換成本低、記憶體佔用少 → 輕鬆支撐上千並發連接，不需要太複雜的中間層 |
| PostgreSQL | 多進程（一個連線 ＝ 一個 Process） | 進程非常吃記憶體，建立連線的開銷很大 |
所以 PgBouncer 不是加分項，是必備技能
應用併發很高（微服務架構，幾千個 Pod 連進來），裸連 PostgreSQL 必死無疑——必須搭配 PgBouncer 這類連線池中間件。
換句話說，選型時要連運維能力一起評估：
- MySQL 對連線管理比較寬容 → 團隊沒有專職 DBA、想開箱即用時的優勢
- 用 PG 則必須具備配置 PgBouncer 的能力
和「慢查詢霸佔連線」接起來
建索引的代價是毫秒，收益可能是秒 講過：一條 14 秒的查詢會佔住一個連線 14 秒，十條就吃掉十個連線，最後連線池耗盡、整個系統癱瘓。
兩篇合起來才是完整的風險：連線本身在 PG 就是昂貴資源（一個進程），而慢查詢會讓這個昂貴資源被長時間佔住。