SQL触发器通常被用来实现审计日志、数据同步、业务规则校验等功能。它依附在表上，由INSERT、UPDATE、DELETE等操作自动触发，既不需要应用层重复编写逻辑，也能保证同一数据库内的数据一致性。但触发器的问题也恰恰来自这种自动化和隐藏性：一次看似普通的UPDATE，可能因为触发器的存在而额外执行多轮扫描、写入甚至级联触发，最终导致锁持有时间变长、事务日志膨胀、CPU和I/O飙升。要治理触发器带来的性能损耗，不能只靠经验判断，需要先理解它的执行模型和虚拟表机制。
一、触发器性能瓶颈的本质
触发器的性能问题大多与inserted和deleted这两个虚拟表有关。以UPDATE操作为例，数据库会把更新前的行放入deleted表，把更新后的行放入inserted表。触发器内部通常需要读取这两个虚拟表来获取变更内容。如果一次UPDATE影响了1000行，inserted和deleted中就会各有1000行。很多人误以为DML触发器是逐行触发的，但实际上在SQL Server和多数关系型数据库中，DML触发器是语句级触发。一次影响1000行的UPDATE只会触发一次触发器，问题的关键在于触发器代码如何操作这些虚拟表。
如果触发器内部使用游标、WHILE循环或逐行变量赋值的方式处理inserted表，就会把本来可以一次性完成的集合操作放大成1000次单行操作。下面这段SQL就是一个典型的高开销触发器写法：
-- 低效写法：逐行处理inserted虚拟表
CREATE TRIGGER trg_Orders_Audit
ON Orders
AFTER UPDATE
AS
BEGIN
DECLARE @OrderID INT, @Status NVARCHAR(50);
DECLARE cur CURSOR FOR
SELECT OrderID, Status FROM inserted;
OPEN cur;
FETCH NEXT FROM cur INTO @OrderID, @Status;
WHILE @@FETCH_STATUS = 0
BEGIN
UPDATE OrderAudit
SET Status = @Status
WHERE OrderID = @OrderID;
FETCH NEXT FROM cur INTO @OrderID, @Status;
END;
CLOSE cur;
DEALLOCATE cur;
END;
GO
这种写法不仅增加了CPU消耗，还会导致触发器内部产生大量单行事务操作。更严重的是，触发器处于原始DML语句的事务边界内。如果触发器执行时间过长，原始UPDATE持有锁的时间也会同步变长，其他会话对这些行的读写都会被阻塞。inserted和deleted是特殊表，虽然数据库内部会尽量利用日志结构，但在大事务下如果频繁JOIN这两个虚拟表与普通表，而普通表又缺少合适索引，执行计划很容易退化为多次全表扫描。
此外，触发器还会增加事务日志写入量。触发器内部对审计表、日志表的写入同样会被记录到事务日志中。如果源表更新频繁，而触发器又写入大量冗余字段，日志吞吐量会成倍上升，进一步影响磁盘I/O和日志备份速度。
二、从执行模型入手做性能优化
优化触发器的第一条原则是让触发器做尽可能少的事。审计日志应该只写必要字段，业务校验可以在应用层先完成，发送邮件、调用外部接口、生成报表等耗时操作绝不应该放在触发器中同步执行。触发器只保留最轻量的同步操作，其他非关键任务可以通过异步队列或定时任务延后处理。
第二条原则是基于集合编写触发器。用一条UPDATE或INSERT语句操作整个inserted或deleted表，而不是用游标逐行处理。下面的改写版本与前面的低效写法形成对比，它直接用一条SQL完成审计状态更新：
-- 高效写法：基于集合更新
CREATE TRIGGER trg_Orders_Audit
ON Orders
AFTER UPDATE
AS
BEGIN
UPDATE oa
SET oa.Status = i.Status,
oa.ModifiedDate = GETDATE()
FROM OrderAudit oa
INNER JOIN inserted i ON oa.OrderID = i.OrderID;
END;
GO
改写后，执行计划只会有一次连接操作，而不是1000次单行索引查找。需要注意的是，如果OrderAudit表的数据量大，其OrderID列必须建立合适索引，否则连接仍然可能退化为哈希或全表扫描。对于以审计为主的大表，可以考虑使用聚集索引或复合索引来优化触发器内部的关联条件。
第三条原则是合并同类触发器。SQL Server中同一个表、同一个事件可以存在多个AFTER触发器，但它们的执行顺序不可控，并且会重复读取inserted和deleted虚拟表。如果Orders表上同时存在三个AFTER UPDATE触发器，分别做审计、状态同步和通知记录，最好将它们合并成一个触发器，在一次虚拟表扫描中完成所有必要操作，减少重复I/O和锁持有时间。
第四条原则是谨慎评估INSTEAD OF触发器。INSTEAD OF触发器可以完全接管DML操作，灵活性更高，但它也绕过了数据库默认的DML执行路径，可能导致索引维护逻辑被跳过，需要手工处理多表视图更新等复杂场景。普通的单表审计和约束校验应优先使用AFTER触发器，因为AFTER触发器在原始DML完成后再执行，对主流程影响更可控。
三、风险防范与治理策略
递归触发与嵌套触发是风险防范的重点。默认情况下，如果数据库启用了递归触发器，触发器在修改自身表时会再次触发自己，形成递归，严重时会造成死循环或栈溢出。嵌套触发器也会让一个操作级联扩展到多个表，一条简单UPDATE最终触发几十个触发器，排查起来非常困难。可以通过数据库设置控制递归触发器和嵌套触发器，例如在SQL Server中检查并调整RECURSIVE_TRIGGERS选项。
-- 查看当前数据库递归触发器设置 SELECT name, is_recursive_triggers_on FROM sys.databases WHERE name = DB_NAME(); -- 关闭递归触发器 ALTER DATABASE CURRENT SET RECURSIVE_TRIGGERS OFF;
除了数据库级设置，还可以在触发器内部使用防重入条件。例如在审计表中增加一个标记列，触发器执行前判断该标记是否已经被更新，从而避免重复处理。不过这种方式会增加表结构和逻辑复杂度，更推荐在源头控制触发器数量和触发链路。
权限与审计同样不可忽视。触发器具备在数据库内部执行任意逻辑的能力，可能被用来隐藏数据修改或绕过应用层校验。应限制创建触发器的权限，只给必要的数据库管理员或高级开发人员。同时要定期查询系统视图，导出触发器定义并纳入版本管理，确保任何人对触发器的修改都可追溯。
-- 查看当前数据库中所有触发器
SELECT name, OBJECT_NAME(parent_id) AS TableName, type_desc
FROM sys.triggers;
-- 查看触发器定义
SELECT OBJECT_DEFINITION(OBJECT_ID('trg_Orders_Audit'));
运维阶段还需要规范禁用与删除操作。临时屏蔽触发器时，优先使用DISABLE TRIGGER而不是DROP TRIGGER，这样可以保留定义，随时恢复。如果确需删除，应先备份完整的触发器脚本。上线新触发器前，应在测试环境模拟大批量数据变更，评估执行计划、事务日志增长和锁等待情况。生产环境中可以通过扩展事件、慢SQL日志或高开销语句视图，持续监控DML执行时间的变化，一旦发现某条UPDATE或INSERT突然变慢，优先检查是否存在新增或修改过的触发器。
触发器的性能治理不是一劳永逸的工作，而是需要结合执行模型、数据库设置和维护习惯持续优化。关键是控制触发器的数量、复杂度和触发链路，避免把核心业务操作隐藏在难以追踪的数据库逻辑中。