PRIMARY KEY 與 UNIQUE 約束深度比較：異同、索引與實務選擇

核心定義速查

本質關係

PRIMARY KEY = UNIQUE + NOT NULL

兩者皆屬實體完整性約束，確保資料列唯一可識別。

關鍵差異詳解

1. NULL 處理

• PK：隱含 NOT NULL，插入 NULL 直接報錯
• UK：允許 NULL，且多筆 NULL 不視為重複（SQL 標準行為，部分 DB 如 SQL Server 僅允許單一 NULL）

2. 索引特性

• 建立 PK 時自動建立 唯一叢集索引（InnoDB、SQL Server 預設），資料實際按 PK 排序存放
• 建立 UK 時自動建立 唯一非叢集索引，葉節點存主鍵值 (InnoDB) 或 RID (Heap 表)
• 可手動指定 UK 為叢集，但一張表只能有一個叢集索引

3. 外鍵關係

FK 參考目標必須是 PK 或 UK。實務上 PK 為首選參考對象，語意更清晰且效能最佳（叢集索引掃描）。

4. 業務語意

• PK：實體識別碼（如 user_id、order_no），不可變、無業務含義（建議用代理鍵）
• UK：業務唯一性（如 email、id_card、phone），可為 NULL、可變更

實務決策指南

1. 每張表必須有 PK：推薦 BIGINT AUTO_INCREMENT 或 UUID 代理鍵
2. 業務唯一欄位加 UK：email、mobile、id_card 等
3. 複合唯一場景：UNIQUE (tenant_id, code) 多租戶隔離
4. 避免業務欄位作 PK：業務變更導致主鍵更新，引發 FK 級聯、索引分裂、複寫風險

常見誤區

「UNIQUE 就能當外鍵參考目標」 → 可行，但需確保非空。若 UK 允許 NULL，參考完整性檢查會忽略 NULL 值，導致孤兒資料。

「PK 一定是叢集索引」 → InnoDB 是，MyISAM/Heap 表不是。MyISAM PK 為非叢集，葉節點存檔案偏移量。

結語

PK 與 UK 雖同為唯一約束，但語意、索引結構、NULL 處理、外鍵角色截然不同。遵循「代理鍵作 PK、業務鍵加 UK」原則，能兼顧效能、擴充性與資料完整性。