触发器中禁止使用while循环，因其违背sql声明式本质且语法不支持；必须用集合操作如update...from或merge替代逐行处理，避免锁争用与性能崩溃。
触发器里写循环逻辑，基本等于主动给数据库加锁、拖慢所有写入——这不是性能“可能变差”，而是必然卡死。
WHILE 循环在触发器中根本不可用
SQL Server 的 WHILE 只能在存储过程或函数体内使用，而触发器本身不支持过程式循环语法。你写的 WHILE 报错，不是写法不对，是语法层面被禁止。试图在 AFTER INSERT 触发器里用 WHILE 遍历 inserted 表，数据库直接拒绝解析。
- 触发器执行模型是“集合驱动”：一次 DML 影响 N 行，
FOR EACH ROW就调用 N 次函数；FOR EACH STATEMENT才能拿到整张inserted表做批量处理 -
WHILE是过程式思维，和 SQL 的声明式本质冲突；强行模拟只会触发 N 次单行查询，变成典型的 N+1 问题 - 即使绕过语法限制（比如在触发器里调用含
WHILE的存储过程），每次循环都会引发额外事务日志写入、锁持有延长、执行计划无法复用
替代方案必须基于集合操作
真要实现“对每条新订单更新对应客户统计”，不能靠循环，得用单条 UPDATE ... FROM inserted 完成。
- 用
UPDATE customers SET total_spent = total_spent + i.amount FROM inserted i WHERE customers.id = i.customer_id，一行搞定批量更新 - 避免在触发器里查聚合结果：
(SELECT SUM(amount) FROM orders WHERE customer_id = i.customer_id)会为每一行重复扫描订单表，改用上面的增量更新 - 如果业务要求“首次下单才初始化客户记录”，用
MERGE INTO customers USING inserted ... WHEN NOT MATCHED THEN INSERT ...，而不是先IF NOT EXISTS再INSERT
高并发下逐行触发器的锁风险
默认 FOR EACH ROW 触发器在批量插入时，会按行顺序依次执行，每行都持有一把行锁，且锁持续到整个事务结束。一旦触发器里有任意延迟（哪怕只是多一个没走索引的 WHERE），就会形成锁等待链。
- 例如：1000 行订单插入 → 触发器调用 1000 次 → 每次更新客户表都要获取
customers.id上的 X 锁 → 如果多个事务同时更新同一客户，立刻排队 - 解决方法只有两个：改用
FOR EACH STATEMENT+ 过渡表（inserted）做集合更新；或彻底移出触发器，改用应用层异步消费 - 别信“加个
NOLOCK就能提速”——读未提交对写操作无帮助，反而可能读到中间状态，破坏一致性
最常被忽略的是：触发器不是业务逻辑的垃圾桶。它只该做三件事——校验约束、维护强一致字段（如 updated_at）、写轻量审计标记。其余所有带分支、聚合、跨表、IO 的逻辑，都应该从触发器里剥离出去。否则，等数据量涨到百万级，你不是在优化 SQL，是在抢救服务。
