在SQL Server中，触发器是与表上的INSERT、UPDATE、DELETE操作绑定的特殊存储过程，它允许开发者在数据变更时自动执行额外逻辑。许多开发人员在触发器内部需要遍历发生变更的行，例如对每一条新插入的记录动态生成编号、逐条同步到审计表或者调用复杂计算。此时，游标往往成为第一选择，因为它提供了灵活的逐行处理能力。然而，这种看似直观的做法在并发环境中会带来严重的性能灾难。
触发器的执行上下文与普通存储过程有本质区别。触发器在触发它的DML语句的事务内部运行，这意味着触发器中的每一步操作都会延长整个事务的持续时间。如果触发器内部使用游标逐行处理数据，那么事务就会在游标打开期间一直持有相关的锁资源。当多个用户同时向该表提交数据时，每个事务都在等待前一个事务的触发器完成游标遍历，阻塞链会迅速累积，最终导致连接池耗尽或应用程序超时。
触发器中使用游标的常见误区
开发团队经常陷入一种思维定式，认为只要数据量不大，在触发器里使用游标就不会造成明显影响。但真实的生产环境中，单条INSERT可能来自批量导入、应用层的循环提交或者合并复制等场景，实际触发频率远超预期。游标的每一次FETCH操作都会产生额外的CPU开销和内存分配，这些开销在单次调用时微不足道，但当触发器被高频调用时，累积效应会让SQL Server的CPU使用率急剧攀升。
另一个常见误区是误以为触发器内的游标只锁住当前行，不会影响其他会话。事实上，游标在默认的READ COMMITTED隔离级别下读取数据时会申请共享锁，而触发器中的写操作则可能申请排他锁。如果游标遍历的是inserted或deleted虚拟表，由于这些表存储在内存中且访问方式特殊，锁的行为可能略有不同，但游标对涉及到的物理表进行更新时，锁会保持到事务提交。这就导致了长时间的行级锁甚至页级锁，进而升级为表级锁。
以下代码展示了在一个AFTER INSERT触发器中滥用游标的典型场景。该游标尝试为每一行新插入的订单数据生成一个流水号并更新回原表。注意代码中使用了DECLARE ... CURSOR进行逐行循环，这种方式会显著拖慢批量插入操作。
CREATE TRIGGER trg_Order_AfterInsert
ON dbo.Orders
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
DECLARE @OrderID INT;
DECLARE @SerialNo VARCHAR(20);
-- 定义游标遍历inserted虚拟表
DECLARE order_cursor CURSOR LOCAL FAST_FORWARD FOR
SELECT OrderID FROM inserted;
OPEN order_cursor;
FETCH NEXT FROM order_cursor INTO @OrderID;
WHILE @@FETCH_STATUS = 0
BEGIN
-- 逐行生成流水号并更新
SET @SerialNo = 'SN' + RIGHT('000000' + CAST(@OrderID AS VARCHAR(10)), 10);
UPDATE dbo.Orders SET SerialNumber = @SerialNo WHERE OrderID = @OrderID;
FETCH NEXT FROM order_cursor INTO @OrderID;
END;
CLOSE order_cursor;
DEALLOCATE order_cursor;
END;
上述代码虽然功能正确，但每次更新都会产生独立的锁请求，并且游标循环期间整个inserted表的所有行都会被逐个处理。如果一次INSERT操作插入了1000条记录，这个触发器就会执行1000次FETCH和1000次UPDATE，而每次UPDATE还需要在Orders表上定位具体行，产生额外的索引查找开销。在并发环境下，这些UPDATE语句还会相互竞争锁资源，导致事务隔离级别下的阻塞延迟被无限放大。
游标引发的锁与并发问题剖析
游标对并发性能的第一重冲击来自锁的持有时间延长。在默认的事务隔离级别下，一条简单的INSERT语句本身只在插入的行上短暂持有排他锁，事务提交后立即释放。但一旦触发器内部打开游标并逐行更新，事务会持续到游标完全关闭并提交时才释放所有锁。这意味着原本毫秒级完成的插入操作，现在可能因为逐行处理而持续数秒甚至数十秒。在这段时间内，其他会话对同一表或相关索引范围的修改请求都会被阻塞。
第二重冲击是锁升级风险的增加。SQL Server会根据锁的数量和内存压力自动将行锁升级为页锁或表锁。触发器内游标的逐行更新会在短时间内产生大量行锁，如果更新涉及的表有索引维护需求，锁的数量会急剧膨胀。一旦触发锁升级，整个表都会被排他锁锁定，所有其他读写操作都无法进行，并发度瞬间降为零。这种情况在批量导入数据时尤其常见，原本可以通过批量操作一次性完成的事务，被触发器拆成了数千个微事务，每个微事务都可能导致锁升级。
第三重冲击是死锁概率的大幅提升。游标的遍历顺序与索引扫描顺序相关，不同的触发器可能按照不同的顺序访问相同的数据页。例如触发器A按主键升序遍历inserted表并更新目标表，而触发器B按外键降序遍历另一张表，两者在交叉更新时很容易形成循环等待。死锁后SQL Server会回滚其中一个事务，这不仅浪费了已经完成的工作，还会让应用程序收到死锁错误，迫使客户端重试，在高峰期形成恶性循环。
通过动态管理视图可以观察到游标触发器带来的锁等待情况。下面的查询可以捕获当前正在等待锁的会话及其等待类型，帮助定位触发器导致的阻塞源。
SELECT
s.session_id,
s.host_name,
s.program_name,
r.blocking_session_id,
r.wait_type,
r.wait_time,
r.last_wait_type,
t.text AS blocking_query
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id > 0;
在生产环境中，如果发现大量会话的阻塞源都指向同一个触发器内部的游标操作，就应该立即考虑重写这段逻辑。等待类型通常表现为LCK_M_X（排他锁等待）和PAGEIOLATCH_SH（数据页读取等待），前者是锁竞争的直接证据，后者则说明游标逐行读取导致的磁盘I/O压力过大。
替代游标的集合操作优化方案
所有能用游标完成的逐行逻辑，几乎都可以改写成基于集合的SQL语句。在触发器内部，inserted和deleted虚拟表提供了当前DML语句影响到的所有行，直接对这两张虚拟表进行关联更新或插入，就能避免逐行处理。前文中的订单流水号生成例子，可以改写为一条UPDATE语句，将inserted表中的OrderID与Orders表关联，使用表达式一次性生成所有流水号。
CREATE TRIGGER trg_Order_AfterInsert_SetBased
ON dbo.Orders
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
UPDATE o
SET o.SerialNumber = 'SN' + RIGHT('000000' + CAST(i.OrderID AS VARCHAR(10)), 10)
FROM dbo.Orders o
INNER JOIN inserted i ON o.OrderID = i.OrderID;
END;
这段代码只执行一次UPDATE操作，SQL Server会利用哈希连接或循环连接在内部批量处理所有行，锁的持有时间大幅缩短，事务也更加紧凑。对于需要复杂条件判断的触发器逻辑，可以先使用SELECT INTO将inserted或deleted的数据复制到临时表，然后基于临时表进行多次集合更新。临时表存储在tempdb中，不会直接阻塞原始表的并发访问，并且可以在临时表上创建索引来加速后续关联查询。
如果触发器中必须处理一些无法用单条语句表达的复杂业务规则，例如需要根据前一行数据计算当前行的累计值，可以考虑使用窗口函数。SQL Server支持SUM() OVER (ORDER BY ...)、ROW_NUMBER() OVER (...)等窗口函数，它们可以在一次扫描中完成累加和排序，完全替代游标的逐行计算。例如需要为每个分区的订单生成递增序号，可以直接使用ROW_NUMBER() OVER (PARTITION BY CustomerID ORDER BY OrderDate)，然后更新回原表。
对于确实无法避免循环处理的极端场景，应该将触发器逻辑转移到应用程序层，或者使用SQL Server的Service Broker队列异步处理。但无论哪种方式，都不应该让触发器在高并发写入路径上执行逐行游标操作。数据库触发器的设计原则是尽量短小、快速、无阻塞，将复杂业务逻辑放在触发器之外执行是更稳妥的选择。
并发性能测试与监控建议
要量化游标触发器对并发性能的冲击，可以通过压力测试模拟多用户同时写入的场景。使用SQL Server自带的sqlcmd或PowerShell脚本并发执行批量INSERT语句，观察事务吞吐量、平均响应时间和锁等待时间的变化。对比使用游标触发器与集合操作触发器时，同样的数据量下系统表现差异明显：游标版本的吞吐量通常只有集合版本的十分之一甚至更低，而且随着并发数增加，性能下降曲线更加陡峭。
在监控层面，需要重点关注以下几个性能计数器：SQL Server Locks对象中的Lock Wait Time和Number of Deadlocks，SQL Server Transactions对象中的Transaction Duration，以及SQL Server Wait Statistics中的LCK_*等待类型。还可以通过扩展事件捕获超过一定阈值的阻塞事件，自动记录阻塞链的SQL文本。这些监控数据能够帮助运维团队及时发现触发器中的游标问题，在故障发生前进行干预。
此外，启用数据库的快照隔离级别可以在一定程度上减少读操作被写操作阻塞的情况，但并不能消除游标触发器的性能瓶颈。快照隔离会让读操作读取行版本，不等待排他锁，但写操作之间的锁冲突依然存在。对于已经上线的系统，如果无法立即重写触发器，可以考虑降低触发器的触发频率，比如将原本逐条触发的AFTER INSERT改为基于批量任务的触发器，或者使用延迟触发器结合队列异步处理变更数据。
总之，SQL Server触发器中的游标使用必须慎之又慎。游标带来的逐行处理开销、锁持有时间延长、锁升级风险和死锁概率提升，会在高并发环境下造成连锁反应，严重影响数据库的整体可用性。开发人员应当优先采用基于inserted和deleted虚拟表的集合操作，利用窗口函数和临时表处理复杂逻辑，从设计源头避免性能陷阱。定期分析锁等待和阻塞数据，及时发现并优化触发器中的低效代码，是保障数据库并发性能的关键环节。
SQL Server触发器游标并发性能修改时间：2026-08-21 03:47:06