1. 范式與反范式的權衡

三大范式回顧

• 1NF：欄位不可再分（原子性）
• 2NF：消除部分依賴（非主鍵完全依賴主鍵）
• 3NF：消除傳遞依賴（非主鍵不依賴非主鍵）

反范式

在 3NF 基礎上引入冗余，減少關聯查詢。前兩范式仍需遵守。

優缺點對比

范式化	反范式化
寫入快、更新快、無冗余、少 GROUP BY/DISTINCT	查詢快（免 JOIN）、利於建立覆蓋索引
缺點：需多表關聯	缺點：寫入慢、數據一致性維護複雜

實戰策略： 核心業務表適度冗余（如實例態表冗余定義態欄位），將多表關聯轉為單表查詢，提升事務內查詢效能。

2. 分表策略

• 狀態分表： 運行態/完成態分離，資料歸檔至歷史表，保持運行態表體積恆定。
• 統計查詢： 要求業務端二選一查詢（運行態或完成態），避免 UNION ALL 大表掃描。
• Hash 分表： 海量數據按關鍵欄位 Hash 取模分表，應用層路由，複雜度由中間件（如 TDDL、ShardingSphere）屏蔽。

3. 匯總表（預聚合）

大數據量報表非實時場景：定時任務（如每晚 00:00-06:00）預計算聚合結果存入匯總表。查詢直接讀匯總表，極速返回。接受 T+1 數據延遲換取查詢效能。

4. 計數器表（熱點行優化）

單行計數器並發衝突嚴重。參考 ConcurrentHashMap 分段鎖思想：

CREATE TABLE hit_counter (
  slot TINYINT UNSIGNED NOT NULL PRIMARY KEY,
  cnt INT UNSIGNED NOT NULL
) ENGINE=InnoDB;

-- 預填 100 槽位
UPDATE hit_counter SET cnt = cnt + 1 WHERE slot = FLOOR(RAND() * 100);
SELECT SUM(cnt) FROM hit_counter;

將單熱點行擴展為 100 行，鎖競爭降低 100 倍，讀取時聚合求和。

總結

資料庫設計無銀彈，需根據業務場景（讀寫比、一致性要求、數據量、團隊能力）在范式/反范式、分表/不分表、實時/離線之間做權衡取捨。