關(guān)于喜憂參半的SQL Server觸發(fā)器詳解
前言
SQL Server觸發(fā)器在非常有爭議的主題。它們能以較低的成本提供便利,但經(jīng)常被開發(fā)人員、DBA誤用,導(dǎo)致性能瓶頸或維護(hù)性挑戰(zhàn)。
本文簡要回顧了觸發(fā)器,并深入討論了如何有效地使用觸發(fā)器,以及何時觸發(fā)器會使開發(fā)人員陷入難以逃脫的困境。
雖然本文中的所有演示都是在SQL Server中進(jìn)行的,但這里提供的建議是大多數(shù)數(shù)據(jù)庫通用的。觸發(fā)器帶來的挑戰(zhàn)在MySQL、PostgreSQL、MongoDB和許多其他應(yīng)用中也可以看到。
什么是觸發(fā)器
可以在數(shù)據(jù)庫或表上定義SQL Server觸發(fā)器,它允許代碼在發(fā)生特定操作時自動執(zhí)行。本文主要關(guān)注表上的DML觸發(fā)器,因為它們往往被過度使用。相反,數(shù)據(jù)庫的DDL觸發(fā)器通常更集中,對性能的危害更小。
觸發(fā)器是對表中數(shù)據(jù)更改時進(jìn)行計算的一組代碼。觸發(fā)器可以定義為在插入、更新、刪除或這些操作的任何組合上執(zhí)行。MERGE操作可以觸發(fā)語句中每個操作的觸發(fā)器。
觸發(fā)器可以定義為INSTEAD OF或AFTER。AFTER觸發(fā)器發(fā)生在數(shù)據(jù)寫入表之后,是一組獨(dú)立的操作,和寫入表的操作在同一事務(wù)執(zhí)行,但在寫入發(fā)生之后執(zhí)行。如果觸發(fā)器失敗,原始操作也會失敗。INSTEAD OF觸發(fā)器替換調(diào)用的寫操作。插入、更新或刪除操作永遠(yuǎn)不會發(fā)生,而是執(zhí)行觸發(fā)器的內(nèi)容。
觸發(fā)器允許在發(fā)生寫操作時執(zhí)行TSQL,而不管這些寫操作的來源是什么。它們通常用于在希望確保執(zhí)行寫操作時運(yùn)行關(guān)鍵操作,如日志記錄、驗證或其他DML。這很方便,寫操作可以來自API、應(yīng)用程序代碼、發(fā)布腳本,或者內(nèi)部流程,觸發(fā)器無論如何都會觸發(fā)。
觸發(fā)器是什么樣的
用WideWorldImporters示例數(shù)據(jù)庫中的Sales.Orders 表舉例,假設(shè)需要記錄該表上的所有更新或刪除操作,以及有關(guān)更改發(fā)生的一些細(xì)節(jié)。這個操作可以通過修改代碼來完成,但是這樣做需要對表的代碼寫入中的每個位置進(jìn)行更改。通過觸發(fā)器解決這一問題,可以采取以下步驟:
1. 創(chuàng)建一個日志表來接受寫入的數(shù)據(jù)。下面的TSQL創(chuàng)建了一個簡單日志表,以及一些添加的數(shù)據(jù)點(diǎn):
CREATE TABLE Sales.Orders_log ( Orders_log_ID int NOT NULL IDENTITY(1,1) CONSTRAINT PK_Sales_Orders_log PRIMARY KEY CLUSTERED, OrderID int NOT NULL, CustomerID_Old int NOT NULL, CustomerID_New int NOT NULL, SalespersonPersonID_Old int NOT NULL, SalespersonPersonID_New int NOT NULL, PickedByPersonID_Old int NULL, PickedByPersonID_New int NULL, ContactPersonID_Old int NOT NULL, ContactPersonID_New int NOT NULL, BackorderOrderID_Old int NULL, BackorderOrderID_New int NULL, OrderDate_Old date NOT NULL, OrderDate_New date NOT NULL, ExpectedDeliveryDate_Old date NOT NULL, ExpectedDeliveryDate_New date NOT NULL, CustomerPurchaseOrderNumber_Old nvarchar(20) NULL, CustomerPurchaseOrderNumber_New nvarchar(20) NULL, IsUndersupplyBackordered_Old bit NOT NULL, IsUndersupplyBackordered_New bit NOT NULL, Comments_Old nvarchar(max) NULL, Comments_New nvarchar(max) NULL, DeliveryInstructions_Old nvarchar(max) NULL, DeliveryInstructions_New nvarchar(max) NULL, InternalComments_Old nvarchar(max) NULL, InternalComments_New nvarchar(max) NULL, PickingCompletedWhen_Old datetime2(7) NULL, PickingCompletedWhen_New datetime2(7) NULL, LastEditedBy_Old int NOT NULL, LastEditedBy_New int NOT NULL, LastEditedWhen_Old datetime2(7) NOT NULL, LastEditedWhen_New datetime2(7) NOT NULL, ActionType VARCHAR(6) NOT NULL, ActionTime DATETIME2(3) NOT NULL, UserName VARCHAR(128) NULL);
該表記錄所有列的舊值和新值。這是非常全面的,我們可以簡單地記錄舊版本的行,并能夠通過將新版本和舊版本合并在一起來了解更改的過程。最后3列是新增的,提供了有關(guān)執(zhí)行的操作類型(插入、更新或刪除)、時間和操作人。
2. 創(chuàng)建一個觸發(fā)器來記錄表的更改:
CREATE TRIGGER TR_Sales_Orders_Audit ON Sales.Orders AFTER INSERT, UPDATE, DELETE AS BEGIN SET NOCOUNT ON; INSERT INTO Sales.Orders_log (OrderID, CustomerID_Old, CustomerID_New, SalespersonPersonID_Old, SalespersonPersonID_New, PickedByPersonID_Old, PickedByPersonID_New, ContactPersonID_Old, ContactPersonID_New, BackorderOrderID_Old, BackorderOrderID_New, OrderDate_Old, OrderDate_New, ExpectedDeliveryDate_Old, ExpectedDeliveryDate_New, CustomerPurchaseOrderNumber_Old, CustomerPurchaseOrderNumber_New, IsUndersupplyBackordered_Old, IsUndersupplyBackordered_New, Comments_Old, Comments_New, DeliveryInstructions_Old, DeliveryInstructions_New, InternalComments_Old, InternalComments_New, PickingCompletedWhen_Old, PickingCompletedWhen_New, LastEditedBy_Old, LastEditedBy_New, LastEditedWhen_Old, LastEditedWhen_New, ActionType, ActionTime, UserName) SELECT ISNULL(Inserted.OrderID, Deleted.OrderID) AS OrderID, Deleted.CustomerID AS CustomerID_Old, Inserted.CustomerID AS CustomerID_New, Deleted.SalespersonPersonID AS SalespersonPersonID_Old, Inserted.SalespersonPersonID AS SalespersonPersonID_New, Deleted.PickedByPersonID AS PickedByPersonID_Old, Inserted.PickedByPersonID AS PickedByPersonID_New, Deleted.ContactPersonID AS ContactPersonID_Old, Inserted.ContactPersonID AS ContactPersonID_New, Deleted.BackorderOrderID AS BackorderOrderID_Old, Inserted.BackorderOrderID AS BackorderOrderID_New, Deleted.OrderDate AS OrderDate_Old, Inserted.OrderDate AS OrderDate_New, Deleted.ExpectedDeliveryDate AS ExpectedDeliveryDate_Old, Inserted.ExpectedDeliveryDate AS ExpectedDeliveryDate_New, Deleted.CustomerPurchaseOrderNumber AS CustomerPurchaseOrderNumber_Old, Inserted.CustomerPurchaseOrderNumber AS CustomerPurchaseOrderNumber_New, Deleted.IsUndersupplyBackordered AS IsUndersupplyBackordered_Old, Inserted.IsUndersupplyBackordered AS IsUndersupplyBackordered_New, Deleted.Comments AS Comments_Old, Inserted.Comments AS Comments_New, Deleted.DeliveryInstructions AS DeliveryInstructions_Old, Inserted.DeliveryInstructions AS DeliveryInstructions_New, Deleted.InternalComments AS InternalComments_Old, Inserted.InternalComments AS InternalComments_New, Deleted.PickingCompletedWhen AS PickingCompletedWhen_Old, Inserted.PickingCompletedWhen AS PickingCompletedWhen_New, Deleted.LastEditedBy AS LastEditedBy_Old, Inserted.LastEditedBy AS LastEditedBy_New, Deleted.LastEditedWhen AS LastEditedWhen_Old, Inserted.LastEditedWhen AS LastEditedWhen_New, CASE WHEN Inserted.OrderID IS NULL THEN 'DELETE' WHEN Deleted.OrderID IS NULL THEN 'INSERT' ELSE 'UPDATE' END AS ActionType, SYSUTCDATETIME() ActionTime, SUSER_SNAME() AS UserName FROM Inserted FULL JOIN Deleted ON Inserted.OrderID = Deleted.OrderID; END
該觸發(fā)器的唯一功能是將數(shù)據(jù)插入到日志表中,每行數(shù)據(jù)對應(yīng)一個給定的寫操作。它很簡單,隨著時間的推移易于記錄和維護(hù),表也會發(fā)生變化。如果需要跟蹤其他詳細(xì)信息,可以添加其他列,如數(shù)據(jù)庫名稱、服務(wù)器名稱、受影響列的行數(shù)或調(diào)用的應(yīng)用程序。
3.最后一步是測試和驗證日志表是否正確。
以下是添加觸發(fā)器后對表進(jìn)行更新的測試:
UPDATE Orders SET InternalComments = 'Item is no longer backordered', BackorderOrderID = NULL, IsUndersupplyBackordered = 0, LastEditedBy = 1, LastEditedWhen = SYSUTCDATETIME() FROM sales.Orders WHERE Orders.OrderID = 10;
結(jié)果如下:
點(diǎn)擊并拖拽以移動
上面省略了一些列,但是我們可以快速確認(rèn)已經(jīng)觸發(fā)了更改,包括日志表末尾新增的列。
INSERT和DELETE
前面的示例中,進(jìn)行插入和刪除操作后,讀取日志表中使用的數(shù)據(jù)。這種特殊的表可以作為任何相關(guān)寫操作的一部分。INSERT將包含被插入操作觸發(fā),DELETE將被刪除操作觸發(fā),UPDATE包含被插入和刪除操作觸發(fā)。
對于INSERT和UPDATE,將包含表中每個列新值的快照。對于DELETE和UPDATE操作,將包含寫操作之前表中每個列舊值的快照。
觸發(fā)器什么時候最有用
DML觸發(fā)器的最佳使用是簡短、簡單且易于維護(hù)的寫操作,這些操作在很大程度上獨(dú)立于應(yīng)用程序業(yè)務(wù)邏輯。
- 觸發(fā)器的一些重要用途包括:
- 記錄對歷史表的更改
- 審計用戶及其對敏感表的操作。
- 向表中添加應(yīng)用程序可能無法使用的額外值(由于安全限制或其他限制),例如:
- 登錄/用戶名
- 操作發(fā)生時間
- 服務(wù)器/數(shù)據(jù)庫名稱
- 簡單的驗證。
關(guān)鍵是讓觸發(fā)器代碼保持足夠的緊湊,從而便于維護(hù)。當(dāng)觸發(fā)器增長到成千上萬行時,它們就成了開發(fā)人員不敢去打擾的黑盒。結(jié)果,更多的代碼被添加進(jìn)來,但是舊的代碼很少被檢查。即使有了文檔,這也很難維護(hù)。
為了讓觸發(fā)器有效地發(fā)揮作用,應(yīng)該將它們編寫為基于設(shè)置的。如果存儲過程必須在觸發(fā)器中使用,則確保它們在需要時使用表值參數(shù),以便可以基于集的方式移動數(shù)據(jù)。下面是一個觸發(fā)器的示例,該觸發(fā)器遍歷id,以便使用結(jié)果順序id執(zhí)行示例存儲過程:
CREATE TRIGGER TR_Sales_Orders_Process ON Sales.Orders AFTER INSERT AS BEGIN SET NOCOUNT ON; DECLARE @count INT; SELECT @count = COUNT(*) FROM inserted; DECLARE @min_id INT; SELECT @min_id = MIN(OrderID) FROM inserted; DECLARE @current_id INT = @min_id; WHILE @current_id < @current_id + @count BEGIN EXEC dbo.process_order_fulfillment @OrderID = @current_id; SELECT @current_id = @current_id + 1; END END
雖然相對簡單,但當(dāng)一次插入多行時對 Sales.Orders的INSERT操作的性能將受到影響,因為SQL Server在執(zhí)行process_order_fulfillment存儲過程時將被迫逐個執(zhí)行。一個簡單的修復(fù)方法是重寫存儲過程,并將一組Order id傳遞到存儲過程中,而不是一次一個地這樣做:
CREATE TYPE dbo.udt_OrderID_List AS TABLE( OrderID INT NOT NULL, PRIMARY KEY CLUSTERED ( OrderID ASC)); GO CREATE TRIGGER TR_Sales_Orders_Process ON Sales.Orders AFTER INSERT AS BEGIN SET NOCOUNT ON; DECLARE @OrderID_List dbo.udt_OrderID_List; EXEC dbo.process_order_fulfillment @OrderIDs = @OrderID_List; END
更改的結(jié)果是將完整的id集合從觸發(fā)器傳遞到存儲過程并進(jìn)行處理。只要存儲過程以基于集合的方式管理這些數(shù)據(jù),就可以避免重復(fù)執(zhí)行,也就是說,避免在觸發(fā)器內(nèi)使用存儲過程有很大的價值,因為它們添加了額外的封裝層,進(jìn)一步隱藏了在數(shù)據(jù)寫入表時執(zhí)行的TSQL。它們應(yīng)該被認(rèn)為是最后的手段,只有當(dāng)可以在應(yīng)用程序的許多地方多次重寫TSQL時才使用。
什么時候觸發(fā)器是危險的
架構(gòu)師和開發(fā)人員面臨的最大挑戰(zhàn)之一是確保觸發(fā)器只在需要時使用,而不允許它們成為一刀切的解決方案。向觸發(fā)器添加TSQL通常被認(rèn)為比向應(yīng)用程序添加代碼更快、更容易,但隨著時間的推移,這樣做的成本會隨著每添加一行代碼而增加。
觸發(fā)器在以下情況下會變得危險:
- 保持盡可能少的觸發(fā)以減少復(fù)雜性。
- 觸發(fā)代碼變得復(fù)雜。如果更新表中的一行導(dǎo)致要執(zhí)行數(shù)千行添加的觸發(fā)器代碼,那么開發(fā)人員就很難完全理解數(shù)據(jù)寫入表時會發(fā)生什么。更糟糕的是,當(dāng)出現(xiàn)問題時,故障排除非常具有挑戰(zhàn)性。
- 觸發(fā)器跨服務(wù)器。這將網(wǎng)絡(luò)操作引入到觸發(fā)器中,可能導(dǎo)致在出現(xiàn)連接問題時寫入速度變慢或失敗。如果目標(biāo)數(shù)據(jù)庫是要維護(hù)的對象,那么即使是跨數(shù)據(jù)庫觸發(fā)器也會有問題。
- 觸發(fā)器調(diào)用觸發(fā)器。觸發(fā)器中最令人痛苦的是,當(dāng)插入一行時,寫操作會導(dǎo)致75個表中有100個觸發(fā)器要執(zhí)行。在編寫觸發(fā)器代碼時,確保觸發(fā)器可以執(zhí)行所有必要的邏輯,而不會觸發(fā)更多觸發(fā)器。額外的觸發(fā)通常是不必要的。
- 遞歸觸發(fā)器被設(shè)置為ON。這是一個默認(rèn)設(shè)置為off的數(shù)據(jù)庫級別設(shè)置。打開時,它允許觸發(fā)器的內(nèi)容調(diào)用相同的觸發(fā)器。遞歸觸發(fā)器會極大地?fù)p害性能,調(diào)試時也會非?;靵y。通常,當(dāng)一個觸發(fā)器中的DML作為操作的一部分觸發(fā)其他觸發(fā)器時,使用遞歸觸發(fā)器。
- 函數(shù)、存儲過程或視圖都在觸發(fā)器中。在觸發(fā)器中封裝更多的業(yè)務(wù)邏輯會使它們變得更復(fù)雜,并給人一種觸發(fā)器代碼短小簡單的錯誤印象,而實際上并非如此。盡可能避免在觸發(fā)器中使用存儲過程和函數(shù)。
- 迭代發(fā)生。循環(huán)和游標(biāo)本質(zhì)上是逐行操作的,可能會導(dǎo)致對1000行的操作一次觸發(fā)1000次,這極大地?fù)p害了查詢性能。
這是一個很長的列表,但通常可以總結(jié)為短而簡單的觸發(fā)器會表現(xiàn)得更好,并避免上面的大多數(shù)陷阱。如果使用觸發(fā)器來維護(hù)復(fù)雜的業(yè)務(wù)邏輯,那么隨著時間的推移,越來越多的業(yè)務(wù)邏輯將被添加進(jìn)來,并且不可避免地將違反上述最佳實踐。
重要的是要注意,為了維護(hù)原子的、事務(wù),受觸發(fā)器影響的任何對象都將保持事務(wù)處于打開狀態(tài),直到該觸發(fā)器完成。這意味著長觸發(fā)器不僅會使事務(wù)持續(xù)時間更長,而且還會持有鎖并導(dǎo)致持續(xù)時間更長。因此,在測試觸發(fā)器時,在為現(xiàn)有觸發(fā)器創(chuàng)建或添加額外邏輯時,應(yīng)該了解它們對鎖、阻塞和等待的影響。
如何改善觸發(fā)器
有很多方法可以使觸發(fā)器更易于維護(hù)、更容易理解和性能更高。以下是一些關(guān)于如何有效管理觸發(fā)器和避免落入陷阱的建議。
觸發(fā)器本身應(yīng)該有良好的文檔記錄:
- 這個觸發(fā)器為什么存在?
- 它能做什么?
- 它是如何工作的?
- 對于觸發(fā)器的工作方式是否有任何例外或警告?
此外,如果觸發(fā)器中的TSQL難以理解,那么可以添加內(nèi)聯(lián)注釋,以幫助第一次查看它的開發(fā)人員。
下面是觸發(fā)器文檔的樣例:
/* 12/29/2020 EHP This trigger logs all changes to the table to the Orders_log table that occur for non-internal customers. CustomerID = -1 signifies an internal/test customer and these are not audited. */ CREATE TRIGGER TR_Sales_Orders_Audit ON Sales.Orders FOR INSERT, UPDATE, DELETE AS BEGIN SET NOCOUNT ON; INSERT INTO Sales.Orders_log (OrderID, CustomerID_Old, CustomerID_New, SalespersonPersonID_Old, SalespersonPersonID_New, PickedByPersonID_Old, PickedByPersonID_New, ContactPersonID_Old, ContactPersonID_New, BackorderOrderID_Old, BackorderOrderID_New, OrderDate_Old, OrderDate_New, ExpectedDeliveryDate_Old, ExpectedDeliveryDate_New, CustomerPurchaseOrderNumber_Old, CustomerPurchaseOrderNumber_New, IsUndersupplyBackordered_Old, IsUndersupplyBackordered_New, Comments_Old, Comments_New, DeliveryInstructions_Old, DeliveryInstructions_New, nternalComments_Old, InternalComments_New, PickingCompletedWhen_Old, PickingCompletedWhen_New, LastEditedBy_Old, LastEditedBy_New, LastEditedWhen_Old, LastEditedWhen_New, ActionType, ActionTime, UserName) SELECT ISNULL(Inserted.OrderID, Deleted.OrderID) AS OrderID, -- The OrderID can never change. --This ensures we get the ID correctly, --regardless of operation type. Deleted.CustomerID AS CustomerID_Old, Inserted.CustomerID AS CustomerID_New, Deleted.SalespersonPersonID AS SalespersonPersonID_Old, Inserted.SalespersonPersonID AS SalespersonPersonID_New, Deleted.PickedByPersonID AS PickedByPersonID_Old, Inserted.PickedByPersonID AS PickedByPersonID_New, Deleted.ContactPersonID AS ContactPersonID_Old, Inserted.ContactPersonID AS ContactPersonID_New, Deleted.BackorderOrderID AS BackorderOrderID_Old, Inserted.BackorderOrderID AS BackorderOrderID_New, Deleted.OrderDate AS OrderDate_Old, Inserted.OrderDate AS OrderDate_New, Deleted.ExpectedDeliveryDate AS ExpectedDeliveryDate_Old, Inserted.ExpectedDeliveryDate AS ExpectedDeliveryDate_New, Deleted.CustomerPurchaseOrderNumber AS CustomerPurchaseOrderNumber_Old, Inserted.CustomerPurchaseOrderNumber AS CustomerPurchaseOrderNumber_New, Deleted.IsUndersupplyBackordered AS IsUndersupplyBackordered_Old, Inserted.IsUndersupplyBackordered AS IsUndersupplyBackordered_New, Deleted.Comments AS Comments_Old, Inserted.Comments AS Comments_New, Deleted.DeliveryInstructions AS DeliveryInstructions_Old, Inserted.DeliveryInstructions AS DeliveryInstructions_New, Deleted.InternalComments AS InternalComments_Old, Inserted.InternalComments AS InternalComments_New, Deleted.PickingCompletedWhen AS PickingCompletedWhen_Old, Inserted.PickingCompletedWhen AS PickingCompletedWhen_New, Deleted.LastEditedBy AS LastEditedBy_Old, Inserted.LastEditedBy AS LastEditedBy_New, Deleted.LastEditedWhen AS LastEditedWhen_Old, Inserted.LastEditedWhen AS LastEditedWhen_New, CASE -- Determine the operation type based on whether --Inserted exists, Deleted exists, or both exist. WHEN Inserted.OrderID IS NULL THEN 'DELETE' WHEN Deleted.OrderID IS NULL THEN 'INSERT' ELSE 'UPDATE' END AS ActionType, SYSUTCDATETIME() ActionTime, SUSER_SNAME() AS UserName FROM Inserted FULL JOIN Deleted ON Inserted.OrderID = Deleted.OrderID WHERE Inserted.CustomerID <> -1 -- -1 indicates an internal/non-production --customer that should not be audited. OR Deleted.CustomerID <> -1; -- -1 indicates an internal/non-production --customer that should not be audited. END
請注意,該文檔并不全面,但包含了一個簡短的頭,并解釋了觸發(fā)器內(nèi)的一些TSQL關(guān)鍵部分:
- 排除CustomerID = -1的情況。這一點(diǎn)對于不知道的人來說是不明顯的,所以這是一個很好的注釋。
- ActionType的CASE語句用于什么。
- 為什么在插入和刪除之間的OrderID列上使用ISNULL。
使用IF UPDATE
在觸發(fā)器中,UPDATE提供了判斷是否將數(shù)據(jù)寫入給定列的能力。這可以允許觸發(fā)器檢查列在執(zhí)行操作之前是否發(fā)生了更改。下面是該語法的示例:
CREATE TRIGGER TR_Sales_Orders_Log_BackorderID_Change ON Sales.Orders AFTER UPDATE AS BEGIN SET NOCOUNT ON; IF UPDATE(BackorderOrderID) BEGIN UPDATE OrderBackorderLog SET BackorderOrderID = Inserted.BackorderOrderID, PreviousBackorderOrderID = Deleted.BackorderOrderID FROM dbo.OrderBackorderLog INNER JOIN Inserted ON Inserted.OrderID = OrderBackorderLog.OrderID END END
通過首先檢查BackorderID是否被更新,觸發(fā)器可以在不需要時繞過后續(xù)操作。這是一種提高性能的好方法,它允許觸發(fā)器根據(jù)所需列的更新值完全跳過代碼。
COLUMNS_UPDATED指示表中的哪些列作為寫操作的一部分進(jìn)行了更新,可以在觸發(fā)器中使用它來快速確定指定的列是否受到插入或更新操作的影響。雖然有文檔記錄,但它使用起來很復(fù)雜,很難進(jìn)行文檔記錄。我通常不建議使用它,因為它幾乎肯定會使不熟悉它的開發(fā)人員感到困惑。
請注意,對于UPDATE或COLUMNS_UPDATED,列是否更改并不重要。對列進(jìn)行寫操作,即使值沒有改變,對于UPDATE操作仍然返回1,對于COLUMNS_UPDATED操作仍然返回1。它們只跟蹤指定的列是否是寫操作的目標(biāo),而不跟蹤值本身是否改變。
每個操作一個觸發(fā)器
讓觸發(fā)代碼盡可能的簡單。數(shù)據(jù)庫表的觸發(fā)器數(shù)量增長會大大增加表的復(fù)雜性,理解其操作變得更加困難。。
例如,考慮以下表觸發(fā)器定義方式:
CREATE TRIGGER TR_Sales_Orders_I ON Sales.Orders AFTER INSERT CREATE TRIGGER TR_Sales_Orders_IU ON Sales.Orders AFTER INSERT, UPDATE CREATE TRIGGER TR_Sales_Orders_UD ON Sales.Orders AFTER UPDATE, DELETE CREATE TRIGGER TR_Sales_Orders_UID ON Sales.Orders AFTER UPDATE, INSERT, DELETE CREATE TRIGGER TR_Sales_Orders_ID ON Sales.Orders AFTER INSERT, DELETE
當(dāng)插入一行時會發(fā)生什么?觸發(fā)器的觸發(fā)順序是什么?這些問題的答案需要研究。維護(hù)更少的觸發(fā)器是一個簡單的解決方案,并且消除了對給定表中如何發(fā)生寫操作的猜測。作為參考,可以使用系統(tǒng)存儲過程sp_settriggerorder修改觸發(fā)器順序,不過這只適用于AFTER觸發(fā)器。
再簡單一點(diǎn)
觸發(fā)器的最佳實踐是操作簡單,執(zhí)行迅速,并且不會因為它們的執(zhí)行而觸發(fā)更多的觸發(fā)器。觸發(fā)器的復(fù)雜程度并沒有明確的規(guī)則,但有一條簡單的指導(dǎo)原則是,理想的觸發(fā)器應(yīng)該足夠簡單,如果必須將觸發(fā)器中包含的邏輯移到其他地方,那么遷移的代價不會高得令人望而卻步。也就是說,如果觸發(fā)器中的業(yè)務(wù)邏輯非常復(fù)雜,以至于移動它的成本太高而無法考慮,那么這些觸發(fā)器很可能變得過于復(fù)雜。
使用我們前面的示例,考慮一下更改審計的觸發(fā)器。這可以很容易地從觸發(fā)器轉(zhuǎn)移到存儲過程或代碼中,而這樣做的工作量并不大。觸發(fā)器中記錄日志的方便性使它值得一做,但與此同時,我們應(yīng)該知道開發(fā)人員將TSQL從觸發(fā)器遷移到另一個位置需要多少小時。
時間的計算可以看作是觸發(fā)器的可維護(hù)性成本的一部分。也就是說,如果有必要,為擺脫觸發(fā)機(jī)制而必須付出的代價。這聽起來可能很抽象,但平臺之間的數(shù)據(jù)庫遷移是很常見的。在SQL Server中執(zhí)行良好的一組觸發(fā)器在Oracle或PostgreSQL中可能并不有效。
優(yōu)化表變量
有時,一個觸發(fā)器中需要臨時表,以允許對數(shù)據(jù)進(jìn)行多次更新。臨時表存儲在tempdb中,并且受到tempdb數(shù)據(jù)庫大小、速度和性能約束的影響。
對于經(jīng)常訪問的臨時表,優(yōu)化表變量是在內(nèi)存中(而不是在tempdb中)維護(hù)臨時數(shù)據(jù)的好方法。
下面的TSQL為內(nèi)存優(yōu)化數(shù)據(jù)配置了一個數(shù)據(jù)庫(如果需要):
ALTER DATABASE WideWorldImporters SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON; ALTER DATABASE WideWorldImporters ADD FILEGROUP WWI_InMemory_Data CONTAINS MEMORY_OPTIMIZED_DATA; ALTER DATABASE WideWorldImporters ADD FILE (NAME='WideWorldImporters_IMOLTP_File_1', FILENAME='C:\SQLData\WideWorldImporters_IMOLTP_File_1.mem') TO FILEGROUP WWI_InMemory_Data;
一旦配置完成,就可以創(chuàng)建一個內(nèi)存優(yōu)化的表類型:
CREATE TYPE dbo.SalesOrderMetadata AS TABLE ( OrderID INT NOT NULL PRIMARY KEY NONCLUSTERED, CustomerID INT NOT NULL, SalespersonPersonID INT NOT NULL, ContactPersonID INT NOT NULL, INDEX IX_SalesOrderMetadata_CustomerID NONCLUSTERED HASH (CustomerID) WITH (BUCKET_COUNT = 1000)) WITH (MEMORY_OPTIMIZED = ON);
這個TSQL創(chuàng)建了演示的觸發(fā)器所需要的表:
CREATE TABLE dbo.OrderAdjustmentLog ( OrderAdjustmentLog_ID int NOT NULL IDENTITY(1,1) CONSTRAINT PK_OrderAdjustmentLog PRIMARY KEY CLUSTERED, OrderID INT NOT NULL, CustomerID INT NOT NULL, SalespersonPersonID INT NOT NULL, ContactPersonID INT NOT NULL, CreateTimeUTC DATETIME2(3) NOT NULL);
下面是一個使用內(nèi)存優(yōu)化表的觸發(fā)器演示:
CREATE TRIGGER TR_Sales_Orders_Mem_Test ON Sales.Orders AFTER UPDATE AS BEGIN SET NOCOUNT ON; DECLARE @OrderData dbo.SalesOrderMetadata; INSERT INTO @OrderData (OrderID, CustomerID, SalespersonPersonID, ContactPersonID) SELECT OrderID, CustomerID, SalespersonPersonID, ContactPersonID FROM Inserted; DELETE OrderData FROM @OrderData OrderData INNER JOIN sales.Customers ON Customers.CustomerID = OrderData.CustomerID WHERE Customers.IsOnCreditHold = 0; UPDATE OrderData SET ContactPersonID = 1 FROM @OrderData OrderData WHERE OrderData.ContactPersonID IS NULL; INSERT INTO dbo.OrderAdjustmentLog (OrderID, CustomerID, SalespersonPersonID, ContactPersonID, CreateTimeUTC) SELECT OrderData.OrderID, OrderData.CustomerID, OrderData.SalespersonPersonID, OrderData.ContactPersonID, SYSUTCDATETIME() FROM @OrderData OrderData; END
觸發(fā)器內(nèi)需要的操作越多,節(jié)省的時間就越多,因為內(nèi)存優(yōu)化的表變量不需要IO來讀/寫。
一旦讀取了來自所插入表的初始數(shù)據(jù),觸發(fā)器的其余部分就可以不處理tempdb,從而減少使用標(biāo)準(zhǔn)表變量或臨時表的開銷。
下面的代碼設(shè)置了一些測試數(shù)據(jù),并運(yùn)行一個更新來演示上述代碼的結(jié)果:
UPDATE Customers SET IsOnCreditHold = 1 FROM Sales.Customers WHERE Customers.CustomerID = 832; UPDATE Orders SET SalespersonPersonID = 2 FROM sales.Orders WHERE CustomerID = 832;
一旦執(zhí)行,OrderAdjustmentLog表的內(nèi)容可以被驗證:
結(jié)果是意料之中的。通過減少對標(biāo)準(zhǔn)存儲的依賴并將中間表移動到內(nèi)存中,內(nèi)存優(yōu)化表提供了一種大大提高觸發(fā)速度的方法。這僅限于對臨時對象有大量調(diào)用的場景,但在存儲過程或其他過程性TSQL中也很有用。
替代觸發(fā)器
像所有的工具一樣,觸發(fā)器也可能被濫用,并成為混亂、性能瓶頸和可維護(hù)性噩夢的根源。有許多比觸發(fā)器更可取的替代方案,在實現(xiàn)(或添加到現(xiàn)有的)觸發(fā)器之前應(yīng)該考慮它們。
Temporal tables
Temporal tables是在SQL Server 2016中引入的,它提供了一種向表添加版本控制的簡單方法,無需構(gòu)建自己的數(shù)據(jù)結(jié)構(gòu)和ETL。這種記錄對應(yīng)用程序是不可見的,并提供了符合ANSI標(biāo)準(zhǔn)的完整版本支持,使之成為一種簡單的方法來解決保存舊版本數(shù)據(jù)的問題。
Check約束
對于簡單的數(shù)據(jù)驗證,Check約束可以提供所需的內(nèi)容,而不需要函數(shù)、存儲過程或觸發(fā)器。在列上定義Check約束,并在創(chuàng)建數(shù)據(jù)時自動驗證數(shù)據(jù)。
下面是一個Check約束的示例:
ALTER TABLE Sales.Invoices WITH CHECK ADD CONSTRAINT CK_Sales_Invoices_ReturnedDeliveryData_Must_Be_Valid_JSON CHECK ([ReturnedDeliveryData] IS NULL OR ISJSON([ReturnedDeliveryData])<>(0))
這段代碼檢查一個列是否是有效的JSON。如果是,則執(zhí)行正常進(jìn)行。如果不是,那么SQL Server將拋出一個錯誤,寫操作將失敗。Check約束可以檢查列和值的任何組合,因此可以管理簡單或復(fù)雜的驗證任務(wù)。
創(chuàng)建Check約束的成本不高,而且易于維護(hù)。它們也更容易記錄和理解,因為Check約束的范圍僅限于驗證傳入數(shù)據(jù)和確保數(shù)據(jù)完整性,而觸發(fā)器實際上可以做任何可以想象的事情!
唯一約束
如果一個列需要唯一的值,并且不是表上的主鍵,那么唯一約束是完成該任務(wù)的一種簡單而有效的方法。唯一約束是索引和唯一性的組合。為了有效地驗證唯一性,索引是必需的。
下面是一個唯一約束的例子:
ALTER TABLE Warehouse.Colors ADD CONSTRAINT UQ_Warehouse_Colors_ColorName UNIQUE NONCLUSTERED (ColorName ASC);
每當(dāng)一行被插入到 Warehouse.Colors表中,將檢查ColorName的唯一性。如果寫操作碰巧導(dǎo)致了重復(fù)的顏色,那么語句將失敗,數(shù)據(jù)將不會被更改。為此目的構(gòu)建了唯一約束,這是在列上強(qiáng)制唯一性的最簡單方法。
內(nèi)置的解決方案將更高效、更容易維護(hù)和更容易記錄。任何看到唯一約束的開發(fā)人員都將立即理解它的作用,而不需要深入挖掘TSQL來弄清事情是如何工作的,這種簡單性使其成為理想的解決方案。
外鍵約束
與Check約束和唯一約束一樣,外鍵約束是在寫入數(shù)據(jù)之前驗證數(shù)據(jù)完整性的另一種方式。外鍵將一一表中的列鏈接到另一張表。當(dāng)數(shù)據(jù)插入到目標(biāo)表時,它的值將根據(jù)引用的表進(jìn)行檢查。如果該值存在,則寫操作正常進(jìn)行。如果不是,則拋出錯誤,語句失敗。
這是一個簡單的外鍵例子:
ALTER TABLE Sales.Orders WITH CHECK ADD CONSTRAINT FK_Sales_Orders_CustomerID_Sales_Customers FOREIGN KEY (CustomerID) REFERENCES Sales.Customers (CustomerID);
當(dāng)數(shù)據(jù)寫入Sales.Orders時,CustomerID列將根據(jù)Sales.Customers中的CustomerID列進(jìn)行檢查。
與唯一約束類似,外鍵只有一個目的:驗證寫入一個表的數(shù)據(jù)是否存在于另一個表中。它易于文檔化,易于理解,實現(xiàn)效率高。
觸發(fā)器不是執(zhí)行這些驗證檢查的正確位置,與使用外鍵相比,它是效率較低的解決方案。
存儲過程
在觸發(fā)器中實現(xiàn)的邏輯通常可以很容易地移動到存儲過程中。這消除了大量觸發(fā)代碼可能導(dǎo)致的復(fù)雜性,同時允許開發(fā)人員更好的維護(hù)。存儲過程可以自由地構(gòu)造操作,以確保盡可能多的原子性。
實現(xiàn)觸發(fā)器的基本原則之一是確保一組操作與寫操作一致。所有成功或失敗都是作為原子事務(wù)的一部分。應(yīng)用程序并不總是需要這種級別的原子性。如果有必要,可以在存儲過程中使用適當(dāng)?shù)母綦x級別或表鎖定來保證事務(wù)的完整性。
雖然SQL Server(和大多數(shù)RDBMS)提供了ACID保證事務(wù)將是原子的、一致的、隔離的和持久的,但我們自己代碼中的事務(wù)可能需要也可能不需要遵循相同的規(guī)則?,F(xiàn)實世界的應(yīng)用程序?qū)?shù)據(jù)完整性的需求各不相同。
存儲過程允許自定義代碼,以實現(xiàn)應(yīng)用程序所需的數(shù)據(jù)完整性,確保性能和計算資源不會浪費(fèi)在不需要的數(shù)據(jù)完整性上。
例如,一個允許用戶發(fā)布照片的社交媒體應(yīng)用程序不太可能需要它的事務(wù)完全原子化和一致。如果我的照片出現(xiàn)在你之前或之后一秒,沒人會在意。同樣,如果你在我編輯照片的時候評論我的照片,時間對使用這些數(shù)據(jù)的人來說可能并不重要。另一方面,一個管理貨幣交易的銀行應(yīng)用程序需要確保交易是謹(jǐn)慎執(zhí)行的,這樣就不會出現(xiàn)資金丟失或數(shù)字報告錯誤的情況。如果我有一個銀行賬戶,里面有20美元,我取出20美元的同時,其他人也取出了20美元,我們不可能都成功。我們中的一個先得到20美元,另一個遇到關(guān)于0美元余額的適當(dāng)錯誤消息。
函數(shù)
函數(shù)提供了一種簡單的方法,可以將重要的邏輯封裝到一個單獨(dú)的位置。在50個表插入中重用的單個函數(shù)比50個觸發(fā)器(每個表一個觸發(fā)器)執(zhí)行相同邏輯要容易得多。
考慮以下函數(shù):
CREATE FUNCTION Website.CalculateCustomerPrice (@CustomerID INT, @StockItemID INT, @PricingDate DATE) RETURNS DECIMAL(18,2) WITH EXECUTE AS OWNER AS BEGIN DECLARE @CalculatedPrice decimal(18,2); DECLARE @UnitPrice decimal(18,2); DECLARE @LowestUnitPrice decimal(18,2); DECLARE @HighestDiscountAmount decimal(18,2); DECLARE @HighestDiscountPercentage decimal(18,3); DECLARE @BuyingGroupID int; DECLARE @CustomerCategoryID int; DECLARE @DiscountedUnitPrice decimal(18,2); SELECT @BuyingGroupID = BuyingGroupID, @CustomerCategoryID = CustomerCategoryID FROM Sales.Customers WHERE CustomerID = @CustomerID; SELECT @UnitPrice = si.UnitPrice FROM Warehouse.StockItems AS si WHERE si.StockItemID = @StockItemID; SET @CalculatedPrice = @UnitPrice; SET @LowestUnitPrice = ( SELECT MIN(sd.UnitPrice) FROM Sales.SpecialDeals AS sd WHERE ((sd.StockItemID = @StockItemID) OR (sd.StockItemID IS NULL)) AND ((sd.CustomerID = @CustomerID) OR (sd.CustomerID IS NULL)) AND ((sd.BuyingGroupID = @BuyingGroupID) OR (sd.BuyingGroupID IS NULL)) AND ((sd.CustomerCategoryID = @CustomerCategoryID) OR (sd.CustomerCategoryID IS NULL)) AND ((sd.StockGroupID IS NULL) OR EXISTS (SELECT 1 FROM Warehouse.StockItemStockGroups AS sisg WHERE sisg.StockItemID = @StockItemID AND sisg.StockGroupID = sd.StockGroupID)) AND sd.UnitPrice IS NOT NULL AND @PricingDate BETWEEN sd.StartDate AND sd.EndDate); IF @LowestUnitPrice IS NOT NULL AND @LowestUnitPrice < @UnitPrice BEGIN SET @CalculatedPrice = @LowestUnitPrice; END; SET @HighestDiscountAmount = ( SELECT MAX(sd.DiscountAmount) FROM Sales.SpecialDeals AS sd WHERE ((sd.StockItemID = @StockItemID) OR (sd.StockItemID IS NULL)) AND ((sd.CustomerID = @CustomerID) OR (sd.CustomerID IS NULL)) AND ((sd.BuyingGroupID = @BuyingGroupID) OR (sd.BuyingGroupID IS NULL)) AND ((sd.CustomerCategoryID = @CustomerCategoryID) OR (sd.CustomerCategoryID IS NULL)) AND ((sd.StockGroupID IS NULL) OR EXISTS (SELECT 1 FROM Warehouse.StockItemStockGroups AS sisg WHERE sisg.StockItemID = @StockItemID AND sisg.StockGroupID = sd.StockGroupID)) AND sd.DiscountAmount IS NOT NULL AND @PricingDate BETWEEN sd.StartDate AND sd.EndDate); IF @HighestDiscountAmount IS NOT NULL AND ( @UnitPrice - @HighestDiscountAmount) < @CalculatedPrice BEGIN SET @CalculatedPrice = @UnitPrice - @HighestDiscountAmount; END; SET @HighestDiscountPercentage = ( SELECT MAX(sd.DiscountPercentage) FROM Sales.SpecialDeals AS sd WHERE ((sd.StockItemID = @StockItemID) OR (sd.StockItemID IS NULL)) AND ((sd.CustomerID = @CustomerID) OR (sd.CustomerID IS NULL)) AND ((sd.BuyingGroupID = @BuyingGroupID) OR (sd.BuyingGroupID IS NULL)) AND ((sd.CustomerCategoryID = @CustomerCategoryID) OR (sd.CustomerCategoryID IS NULL)) AND ((sd.StockGroupID IS NULL) OR EXISTS (SELECT 1 FROM Warehouse.StockItemStockGroups AS sisg WHERE sisg.StockItemID = @StockItemID AND sisg.StockGroupID = sd.StockGroupID)) AND sd.DiscountPercentage IS NOT NULL AND @PricingDate BETWEEN sd.StartDate AND sd.EndDate); IF @HighestDiscountPercentage IS NOT NULL BEGIN SET @DiscountedUnitPrice = ROUND(@UnitPrice * @HighestDiscountPercentage / 100.0, 2); IF @DiscountedUnitPrice < @CalculatedPrice SET @CalculatedPrice = @DiscountedUnitPrice; END; RETURN @CalculatedPrice; END;
就復(fù)雜性而言,這絕對是一頭猛獸。雖然它接受標(biāo)量參數(shù)來確定計算價格,但它執(zhí)行的操作非常大,甚至包括對Warehouse.StockItemStockGroups, Warehouse.StockItems和Sales.Customers的額外讀取。如果這是一個經(jīng)常針對單行數(shù)據(jù)使用的關(guān)鍵計算,那么將其封裝在一個函數(shù)中是獲得所需計算的一種簡單方法,而不會增加觸發(fā)器的復(fù)雜性。小心使用函數(shù),并確保使用大型數(shù)據(jù)集進(jìn)行測試。簡單的標(biāo)量函數(shù)通??梢院芎玫厣炜s性較大的數(shù)據(jù),但更復(fù)雜的函數(shù)可能性能較差。
編碼
當(dāng)從應(yīng)用程序修改表中的數(shù)據(jù)時,還可以在寫入數(shù)據(jù)之前執(zhí)行額外的數(shù)據(jù)操作或驗證。這通常代價低廉,性能很好,并有助于減少失控觸發(fā)器對數(shù)據(jù)庫的負(fù)面影響。
將代碼放入觸發(fā)器的常見理由是,這樣做可以避免修改代碼、推送構(gòu)建,否則會導(dǎo)致更改應(yīng)用程序。這與在數(shù)據(jù)庫中進(jìn)行更改相關(guān)的任何風(fēng)險直接相反。這通常是應(yīng)用程序開發(fā)人員和數(shù)據(jù)庫開發(fā)人員之間關(guān)于誰將負(fù)責(zé)新代碼的討論。
這是一個粗略的指導(dǎo)方針,但有助于在代碼添加到應(yīng)用程序或觸發(fā)器之后測量可維護(hù)性和風(fēng)險。
計算列
其他列發(fā)生更改時,計算列可以包括通過各種各樣的算術(shù)運(yùn)算和函數(shù)進(jìn)行計算,得到結(jié)果。它們可以包含在索引中,也可以包含在唯一的約束中,甚至主鍵中。
當(dāng)任何底層值發(fā)生變化時,SQL Server會自動維護(hù)計算的列。注意,每個計算出來的列最終都是由表中其他列的值決定的。
這是使用觸發(fā)器來維護(hù)指定列值的一種很好的替代方法。計算列是高效的、自動的,并且不需要維護(hù)。它們只是簡單地工作,甚至允許將復(fù)雜的計算直接集成到一個表中,而在應(yīng)用程序或SQL Server中不需要額外的代碼。
使用SQL Server觸發(fā)器
觸發(fā)器在SQL Server中是一個有用的特性,但像所有工具一樣,它也可能被誤用或濫用。在決定是否使用觸發(fā)器時,一定要考慮觸發(fā)器的目的。
如果一個觸發(fā)器被用來將簡短的事務(wù)數(shù)據(jù)寫入日志表,那么它很可能是一個很好的觸發(fā)器。如果觸發(fā)器被用來強(qiáng)制執(zhí)行復(fù)雜的業(yè)務(wù)規(guī)則,那么很可能需要重新考慮處理這類操作的最佳方式。
有很多工具可以作為觸發(fā)器的可行替代品,比如檢查約束、計算列等,解決問題的方法并不短缺。數(shù)據(jù)庫體系結(jié)構(gòu)的成功在于為工作選擇正確的工具。
原文鏈接:https://www.red-gate.com/simple-talk/sql/database-administration/sql-server-triggers-good-scary/
總結(jié)
到此這篇關(guān)于關(guān)于SQL Server觸發(fā)器的文章就介紹到這了,更多相關(guān)SQL Server觸發(fā)器內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
- 利用SQL Server觸發(fā)器實現(xiàn)表的歷史修改痕跡記錄
- SQLSERVER對加密的存儲過程、視圖、觸發(fā)器進(jìn)行解密(推薦)
- SQL Server 使用觸發(fā)器(trigger)發(fā)送電子郵件步驟詳解
- SQL Server實現(xiàn)用觸發(fā)器捕獲DML操作的會話信息【實例】
- SQL Server:觸發(fā)器實例詳解
- SqlServer觸發(fā)器詳解
- SqlServer實現(xiàn)類似Oracle的before觸發(fā)器示例
- SQL SERVER中各類觸發(fā)器的完整語法及參數(shù)說明
- SQL SERVER 觸發(fā)器介紹
- SQL Server誤區(qū)30日談 第4天 DDL觸發(fā)器就是INSTEAD OF觸發(fā)器
- SQL Server 觸發(fā)器詳情
相關(guān)文章
將所有符合條件的結(jié)果拼接成一列并用逗號隔開的一個sql語句
把所有符合條件的結(jié)果拼接成一列,用逗號隔開的一個sql語句。2010-06-06sql lite 數(shù)據(jù)庫之間表復(fù)制的方法
最近用sql lite數(shù)據(jù)庫,因為數(shù)據(jù)庫版本的問題,導(dǎo)致數(shù)據(jù)庫中的數(shù)據(jù)表內(nèi)容不同步,所以需要整合二個數(shù)據(jù)庫中的對應(yīng)表及其表中數(shù)據(jù)。2013-04-04一列保存多個ID(將多個用逗號隔開的ID轉(zhuǎn)換成用逗號隔開的名稱)
在做項目時,經(jīng)常會遇到這樣的表結(jié)構(gòu)在主表的中有一列保存的是用逗號隔開ID2012-07-07vs code連接sql server數(shù)據(jù)庫步驟及遇到的問題小結(jié)
這篇文章主要介紹了用vs code連接sql server數(shù)據(jù)庫步驟及遇到的問題,本文通過圖文并茂的形式給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-05-05SQL?Server2019安裝后出現(xiàn)連接失敗的解決方法
在開發(fā)中我們經(jīng)常會用到SQL?Server,下面這篇文章主要給大家介紹了關(guān)于SQL?Server2019安裝后出現(xiàn)連接失敗的解決方法,文中通過圖文介紹的非常詳細(xì),需要的朋友可以參考下2022-12-12