您现在的位置：程式碼之家 >> 數據庫知識 > >> SQL Server 資料庫 >> 關於SqlServer

約束 vs DML 觸發器：資料庫完整性執行的正確選擇指南

編輯：關於SqlServer

開發者常在「何時用約束、何時用觸發器」上猶豫不決，甚至混用導致邏輯衝突、效能倒退。本文從執行時機、效能特性、適用場景三個維度，建立清晰的決策框架，並以實戰案例對比外鍵約束與觸發器實現參考完整性的差異。

核心差異速查表

維度	約束	DML 觸發器 (AFTER)
執行階段	資料寫入引擎前 (編譯期即可驗證元數據)	資料寫入完成後 (已產生日誌、持有鎖)
回滾成本	極低 (未產生實際資料頁修改)	高 (已寫入資料頁、日誌，需補償性刪除/回滾)
效能優化	優化器原生感知，可簡化執行計畫、推導統計資訊	黑盒，優化器無法洞察內部邏輯
維護成本	宣告式，零程式碼	程序式，需編寫/除錯/版控 T-SQL
適用邏輯	單列/跨列/跨表「靜態規則」 (值域、唯一性、參考完整性)	「動態規則」 (歷史比較、跨表聚合、稽核、複雜業務流程)

案例對比：外鍵約束 vs 觸發器實現參考完整性

場景：SalesHistory.Product 必須存在於 I_SalesProducts.Product

✅ 外鍵約束 (推薦)：

ALTER TABLE SalesHistory
ADD CONSTRAINT FK_SalesHistory_Product
FOREIGN KEY (Product) REFERENCES I_SalesProducts(Product);

引擎內部以極輕量鎖 (Sch-S / RangeS-S) 驗證，近零開銷。
支援級聯動作 (CASCADE UPDATE/DELETE)、NOCHECK 既有資料。
執行順序：INSTEAD OF Trigger → FK 約束 → AFTER Trigger。FK 在 AFTER Trigger 前生效，保證觸發器看到的資料已通過參考完整性檢查。

❌ 觸發器實現 (反模式)：

CREATE TRIGGER TR_SalesHistory_FK ON SalesHistory
FOR INSERT, UPDATE
AS
BEGIN
    IF UPDATE(Product) AND @@ROWCOUNT <> (
        SELECT COUNT(*) FROM inserted i
        JOIN I_SalesProducts s ON i.Product = s.Product
    )
    BEGIN
        ROLLBACK TRANSACTION;
        THROW 50001, 'Product 不存在於主檔', 1;
    END
END

需手動處理多列主鍵、NULL 語意、並發下的 Phantom Read（需 Serializable 隔離或鎖 Hint）。
觸發器內 Join 系統表/用戶表，引入額外鎖競爭。
若主檔同時被大量更新，觸發器驗證查詢易成為熱點。

觸發器的正確戰場：歷史比較與動態業務規則

案例： 「BigScreen 產品單日銷售額 < $500 時，筆數不得超過 5 筆」

此規則需：

比較「當前交易」與「今日既有交易」的聚合結果。
涉及時間窗口 (Today)、價格閾值、產品分類等動態條件。
無法用靜態約束表達 (CHECK 無法跨列聚合、無法存取其他列)。

觸發器實現：

CREATE TRIGGER TR_MaxDailySales ON SalesHistory
FOR INSERT, UPDATE
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @Today DATE = CAST(GETDATE() AS DATE);
    DECLARE @Product VARCHAR(20) = 'BigScreen';
    DECLARE @MaxCount TINYINT = 5;
    DECLARE @PriceThreshold MONEY = 500;

    DECLARE @InsertedCount INT = (
        SELECT COUNT(*) FROM inserted
        WHERE Product = @Product AND SalePrice < @PriceThreshold AND SaleDate = @Today
    );
    DECLARE @ExistingCount INT = (
        SELECT COUNT(*) FROM SalesHistory
        WHERE Product = @Product AND SalePrice < @PriceThreshold AND SaleDate = @Today
    );

    IF @InsertedCount + @ExistingCount > @MaxCount
    BEGIN
        ROLLBACK TRANSACTION;
        THROW 50002, '單日特價銷售超額', 1;
    END
END

決策樹：三步判斷用約束還是觸發器

規則能否用單一資料列的欄位值、或同列其他資料列的靜態關係表達？ → 能 → 約束 (CHECK, UNIQUE, FK, PK)
規則是否涉及「歷史資料聚合」、「時間窗口」、「跨表非參考關係」、「稽核軌跡」？ → 是 → 觸發器 (或應用層 + 交易腳本)
規則是否需在寫入前攔截 (如防止惡意資料污染日誌)？ → 是 → INSTEAD OF Trigger 或約束 (約束更早攔截)

最佳實踐原則

約束優先： 能用約束解決的，絕不寫觸發器。
觸發器單一職責： 一個觸發器只執行一類業務邏輯，避免萬能觸發器膨脹。
避免巢狀觸發： 關閉 nested triggers 伺服器選項，或在觸發器開頭 IF TRIGGER_NESTLEVEL() > 1 RETURN。
文檔化： 在資料字典/ER 圖中標註每個約束/觸發器對應的業務規則編號，便於追溯與影響分析。

約束是資料庫的「免疫系統」，觸發器是「特種部隊」。讓免疫系統處理日常病毒，特種部隊處理特種作戰，資料庫才能長治久安。