SQL Server 資料庫表主鍵設計最佳實踐與避坑指南

前言：為何主鍵設計至關重要？

隨著企業數據量爆發式增長，關係型資料庫（如 SQL Server、Oracle、DB2）已成為核心數據存儲引擎。無論前端採用 C/S 還是 B/S 架構，後端資料庫設計的合理性直接決定系統性能與可維護性。本文針對 SQL Server 環境，深入探討表主鍵設計的常見誤區與優化策略。

現狀剖析：業務邏輯主導的聯合主鍵陷阱

典型場景：訂單主從表的鍵值蔓延

以銷售系統為例：主表 SalesOrder 以單據號為主鍵；明細表 SalesDetail 需包含單據號與商品編碼組成聯合主鍵。若業務進一步細分（如同一商品不同價格策略），第三張表甚至需引入前兩表的所有鍵值，形成三級甚至多級聯合主鍵。

核心問題

• 數據冗餘存儲： 從表被迫重複存儲主表所有主鍵欄位，隨業務層級加深，冗餘呈指數級增長。
• SQL 複雜度飆升： 多欄位 JOIN 條件導致查詢語句冗長，優化器難以生成高效執行計劃。
• 應用層參數傳遞負擔： 多層聯查需傳遞多個鍵值參數，增加介面耦合度。
• 索引與查詢效率雙重受損： 聯合主鍵自動建立聯合索引，索引寬度大、深度深，篩選效率低；WHERE 子句需匹配多欄位，CPU 開銷大。
• Web 分頁技術難題： 聯合主鍵缺乏單一遞增特性，難以實現高效的 Keyset 分頁或游標分頁。

解決方案：代理鍵（Surrogate Key）重構策略

核心原則

採用無業務含義的單一自增整數（IDENTITY）或 GUID作為主鍵（代理鍵），業務唯一性通過 UNIQUE 約束或唯一索引保證。

重構示例

-- 主表
CREATE TABLE SalesOrder (
    OrderID     INT IDENTITY(1,1) PRIMARY KEY,  -- 代理鍵
    OrderNo     VARCHAR(20) NOT NULL UNIQUE,    -- 業務單號
    TotalAmount MONEY,
    ...
);

-- 明細表
CREATE TABLE SalesDetail (
    DetailID    INT IDENTITY(1,1) PRIMARY KEY,  -- 代理鍵
    OrderID     INT NOT NULL REFERENCES SalesOrder(OrderID), -- 外鍵關聯
    ProductCode VARCHAR(20) NOT NULL,
    PriceType   TINYINT NOT NULL,               -- 價格策略區分
    Qty         INT,
    Amount      MONEY,
    UNIQUE (OrderID, ProductCode, PriceType)    -- 業務唯一性
);

優勢總結

特殊場景處理建議

• 分庫分表/合併場景： 採用 BIGINT 配合雪花算法或 NEWSEQUENTIALID() 生成全局唯一鍵。
• 唯讀歷史表： 可保留自然鍵作為主鍵，但需評估查詢模式。
• 現有系統改造： 新增代理鍵列，建立唯一索引，逐步切換外鍵引用，最後調整主鍵（需停機窗口）。

結語

主鍵設計應遵循「單一、無意義、窄、遞增」原則。代理鍵雖增加一列存儲，卻能換取查詢性能、開發效率與系統擴展性的全面提升。在 SQL Server 中，INT IDENTITY 仍是 90% 以上 OLTP 表的最佳選擇。