垂直擴展換機器，水平擴展換複雜度

	做法	白話
垂直擴展（scale up）	把同一台機器變強	4 核 → 64 核，16G → 512G，HDD → NVMe
水平擴展（scale out）	加更多台機器	1 台 → 100 台

為什麼關聯式資料庫傳統上偏向垂直

因為它承諾的東西需要「看得到全部資料」：

• JOIN 要能配對任意兩張表的任意兩列
• 交易要能原子地改動任意幾列
• 外鍵約束要能檢查另一張表

資料全在一台機器上時，這些都是本機操作。 散到 100 台之後，JOIN 變跨網路、交易變分散式協調（2PC）、外鍵檢查變遠端查詢——複雜度和延遲都是階躍式上升。所以最省事的做法就是：別拆，換一台更大的。

垂直的天花板

問題	說明
硬體上限	單機核心數、記憶體有物理極限，到頂就沒了
成本非線性	效能 2 倍的機器，價格往往遠超 2 倍
單點故障	一台機器，掛了就全掛
升級要停機	雲端好一些，但通常仍要重啟

水平剛好相反：理論上沒有上限，但複雜度就是你付的代價。

「RDB 只能垂直擴展」已經過時了一半

RDB 其實有一整排水平選項，差別在各自擴的是什麼：

讀取副本（read replica）  → 只能擴讀，寫還是單點
分區（partitioning）      → 同一台機器內切表，不是真的擴展
Vitess / Citus            → 在 MySQL / PostgreSQL 上做真分片
CockroachDB / Spanner     → 原生分散式 SQL

真的要水平分片時，怎麼決定資料落在哪台，見 key-range sharding 用順序換熱點，hash 用均勻換範圍查詢。