資料庫主鍵設計哲學：從王菲的故事談對象識別碼

引言：一個關於身份識別的故事

王菲從出生時的「王菲」，到同學間的「大王菲」，再到身份證號「100321690808022」，香港發展時的「王靖雯」，最終回歸「王菲」。每個階段的「主鍵」都隨著情境變更，導致歌迷資料庫關聯混亂。這個故事生動詮釋了資料庫設計中主鍵不應使用業務屬性的核心原則。

什麼是主鍵？

關聯式資料庫要求每個資料表必須有主鍵，以唯一識別每一列。主鍵可以是單欄或複合欄，值不可重複。主鍵是資料表間建立關聯的基礎，體現「關聯」的本質。

常見錯誤：將物件屬性當作物件識別碼

這些都是物件屬性：業務邏輯上可變的資訊。它們的唯一性由業務規則保證，而非本質保證。

正確觀念：物件識別碼

• 唯一性：即使屬性完全相同，識別碼也不同（如同名同生日的兩個王菲）。
• 永恆不變：物件一誕生，識別碼即確定，無論屬性如何變更，識別碼不變。
• 無業務含義：純粹為區分物件而存在，不攜帶任何業務語意。
• 關聯基礎：所有關聯皆建立在識別碼之上，避免屬性變更導致關聯斷裂。

實務主鍵選擇策略

1. 自增整數

優點：簡單、空間小、效能佳。缺點：分散式環境需處理種子衝突；高併發下可能成鎖爭用熱點。

2. GUID / UUID

優點：無需中央協調、天然適合分散式同步。缺點：佔用 16 位元組、索引碎片嚴重、隨機 I/O 影響效能。

3. 有序 GUID (COMB) / 時間序列 ID

結合時間遞增特性與隨機性，新產生的 ID 大於舊 ID，大幅減少索引碎片與隨機 I/O，兼具分散式唯一性與查詢效能。

索引結構優化建議

• 主鍵建立叢集索引：資料與索引同結構，查找最快，且鍵值不變可減少頁分裂與碎片。
• 若查詢多為近期資料，自增主鍵可設遞減或倒序，配合磁碟循序讀取特性提升效能。
• 避免使用純隨機 GUID 作為叢集鍵，導致 B-Tree 節點頻繁分裂、磁頭亂跳。

結語

主鍵設計的最高原則：專用識別碼欄位，完全脫離業務屬性。無論選用自增整數、GUID 或有序 ID，核心在於識別碼的唯一、永恆、無業務語意三大特質。這是通往物件導向資料庫設計的門檻，也是高效能、可維護系統的基石。