SQL Server 唯一性約束 vs 唯一索引：選擇指南與實戰差異

當需要確保資料行值唯一時，SQL Server 提供兩種機制：UNIQUE CONSTRAINT (唯一性約束) 與 UNIQUE INDEX (唯一索引)。兩者在查詢最佳化上效能相同，但在語意、標準相容性、管理工具呈現與變更彈性上有關鍵差異。本文透過實戰範例詳細比較，協助做出正確選擇。

核心差異速覽

實戰示範：從約束到索引的演進

1. 建立資料表與 UNIQUE CONSTRAINT

CREATE TABLE dbo.CAR (
    CarID INT IDENTITY(1,1) NOT NULL,
    Make VARCHAR(10) NOT NULL,
    Model VARCHAR(10) NOT NULL,
    TotalDoors TINYINT NOT NULL,
    TotalCylinders TINYINT NOT NULL,
    CONSTRAINT PK_CAR PRIMARY KEY NONCLUSTERED (CarID),
    CONSTRAINT UQ_CAR UNIQUE NONCLUSTERED (Make, Model)
);
GO

2. 檢查物件 (sp_help CAR)

執行 sp_help CAR 可見：

• 約束 UQ_CAR 存在於「約束」清單
• 同名唯一非叢集索引 UQ_CAR 存在於「索引」清單
• 系統自動以約束名稱命名索引

3. 業務變更：需加入 Year 欄位並納入唯一性

嘗試直接 DROP INDEX 並 CREATE UNIQUE INDEX 包含 Year：

DROP INDEX dbo.CAR.UQ_CAR;
GO
CREATE UNIQUE INDEX UQ_CAR ON dbo.CAR (Make, Model, [Year]);
GO

報錯：無法卸除索引 'UQ_CAR'，因為它是由約束 'UQ_CAR' 強制執行的。

4. 正確做法：DROP CONSTRAINT 再 ADD CONSTRAINT

ALTER TABLE dbo.CAR DROP CONSTRAINT UQ_CAR;
GO
ALTER TABLE dbo.CAR ADD CONSTRAINT UQ_CAR UNIQUE (Make, Model, [Year]);
GO

再次 sp_help CAR 驗證，約束與索引皆已更新包含 Year。

5. 效能調整：改為叢集索引

若所有報表皆依 Make, Model, Year 排序，將唯一性約束改為叢集索引可避免 Key Lookup：

CREATE UNIQUE CLUSTERED INDEX UQ_CAR ON dbo.CAR (Make, Model, [Year])
WITH DROP_EXISTING;
GO

關鍵點：DROP_EXISTING 允許在不變更索引鍵欄位順序/組成的前提下，直接轉換叢集/非叢集屬性。若需增減欄位，仍須走 DROP CONSTRAINT → ADD CONSTRAINT 流程。

最佳實務建議

1. 預設選擇 UNIQUE CONSTRAINT：符合 ANSI 標準，語意清晰表達「業務規則：此欄位組合不可重複」，文件化效果優於索引。
2. 需頻繁變更欄位組合時：考慮直接使用 UNIQUE INDEX，DROP/CREATE 較無約束依賴阻礙。
3. 效能調整 (叢集/非叢集、INCLUDE 欄位、篩選索引)：使用 CREATE UNIQUE INDEX ... WITH DROP_EXISTING 或重建約束。
4. 命名規範：約束建議 UQ_Table_Columns，索引建議 IX_Table_Columns，避免同名混淆。
5. 文件化：在資料字典/ERD 標註唯一性來源 (約束/索引)，利於團隊維護。

結論

UNIQUE CONSTRAINT 與 UNIQUE INDEX 在查詢效能上等價，差異在於語意層級與變更管理。建議優先使用約束表達業務規則，僅在需要索引層級精細控制 (如 INCLUDE、WHERE 篩選、頻繁結構變更) 時改用索引。理解兩者轉換機制 (DROP_EXISTING、約束依賴)，能避免線上變更時的阻塞與報錯。