資料庫主鍵與外鍵設計原則：從邏輯到物理的落地指南

核心定位：主鍵是物理模型的基石

關聯式資料庫靠主鍵（PK）與外鍵（FK）將離散資料表編織成一致的資料網絡。PK 在物理層僅有兩大職責：

1. 唯一識別單一資料列（Entity Integrity）。
2. 供外鍵參考，建立父子關聯（Referential Integrity）。

一旦進入生產環境，修改鍵結構極高風險（需重建索引、重寫應用、停機遷移），故設計階段必須定案。

主鍵設計五大鐵律

1. 業務無意義

PK 不應攜帶任何業務語義（如發票號、身分證字號、UUID 等）。若使用者看見連接表的 PK 覺得「沒用」，代表設計正確——它純粹為系統服務，避免業務變更牽動鍵值更新。

2. 單欄優先

單欄 PK（BIGINT AUTO_INCREMENT、UUID、SNOWFLAKE ID）可大幅提升 JOIN、篩選、索引維護效能。複合鍵常見誤區：

• 「PK 應有業務意義」→ 違反原則 1，導致未來業務調整需更新 PK。
• 「多對多連接表用兩個 FK 組合成 PK」→ 當此連接表再成為上層父表時，子表 FK 需攜帶雙欄，層層疊加導致鍵寬度爆炸，嚴重拖垮索引與緩存效率。

3. 永不更新

PK 唯一職責是識別，無更新理由。若業務需「修改識別碼」，實為刪除舊列、插入新列的業務邏輯，不應在資料庫層面 UPDATE PK。

4. 排除動態資料

時間戳、建立時間、修改時間等會隨資料變動的欄位，絕不可納入 PK。

5. 電腦自動產生

人為干預產生 PK（如手工指定 ID）會引入業務語義，進而誘發更新慾望。採用資料庫原生序列、AUTO_INCREMENT、UUID() 或分散式 ID 生成器（Snowflake、Leaf）。

外鍵設計實務建議

• 明確宣告 FK 约束：資料庫層面強制參考完整性，避免應用層漏寫導致孤兒資料。
• ON UPDATE/DELETE 行為显性化：根據業務語義選擇 CASCADE、SET NULL、RESTRICT、NO ACTION，並在資料字典文檔化。
• 索引自動建立：InnoDB 會自動在 FK 欄位建立索引；若手動建立 FK 前已有索引，會複用，避免重複。
• 大量匯入時暫停 FK 檢查：SET FOREIGN_KEY_CHECKS=0; 匯入完成後重開並驗證一致性。

常見反模式與修正

總結

主鍵是「系統身分證」，外鍵是「關係契約」。堅守無業務意義、單欄、不更新、自動產生四大原則，配合明確的 FK 宣告與級聯策略，即可構建穩健、可演進的物理資料模型。