sql server触发器中可用try…catch，但仅限after和instead of触发器；必须将全部dml逻辑包在begin try内，catch中须立即提取error_*()值并用throw重抛，否则错误静默丢失。
触发器里不能用 TRY...CATCH？那怎么捕获错误
SQL Server 触发器中 TRY...CATCH 是可用的，但仅限于 **AFTER 触发器**；INSTEAD OF 触发器也能用，但 FOR INSERT/UPDATE/DELETE（等价于 AFTER）才支持完整错误上下文。关键点在于：触发器内发生的错误若未被 CATCH 捕获，会直接回滚整个事务并抛出错误——用户看到的就是语句失败，而你的日志或补偿逻辑根本没机会执行。
实操建议：
- 所有业务逻辑包裹在
BEGIN TRY ... END TRY内，CATCH块必须包含THROW或显式RAISERROR，否则错误静默吞掉 - 避免在
CATCH里写复杂 SQL（比如跨库插入日志），因为当前事务已处于不可提交状态；优先用INSERT INTO @ErrorLogTable（内存表）暂存信息，再由外部作业处理 - 注意
ERROR_LINE()返回的是触发器内部行号，不是调用语句位置，调试时得对照触发器源码
INSERTED/DELETED 为空时触发器崩溃怎么办
触发器被设计为“每条语句触发一次”，不是“每行触发一次”。当 UPDATE 影响 0 行时，DELETED 和 INSERTED 仍存在但为空集——如果代码直接 SELECT ... FROM INSERTED 且没加 IF EXISTS (SELECT 1 FROM INSERTED) 判断，后续引用字段就会报 Invalid column name 或空值参与计算导致逻辑错乱。
实操建议：
- 所有对
INSERTED或DELETED的访问前，先检查：IF NOT EXISTS (SELECT 1 FROM INSERTED) RETURN - 需要取单值（如主键）时，别用
(SELECT id FROM INSERTED)，改用(SELECT TOP (1) id FROM INSERTED)并配合ISNULL(..., 0)防 NULL - 批量操作场景下，永远按集合思维写逻辑，别假设只有一行——哪怕业务上“每次只改一条”，SQL Server 仍可能合并执行
触发器修改自身表引发递归死锁怎么破
触发器里执行 UPDATE 同一张表（比如审计字段自动更新），默认开启 RECURSIVE_TRIGGERS 时会再次触发自身，形成无限循环；即使关掉递归，也可能因锁升级（从 ROW 到 PAGE）导致阻塞甚至死锁。
实操建议：
- 用
IF TRIGGER_NESTLEVEL() > 1 RETURN快速退出嵌套调用，这是最轻量的防护 - 避免在触发器里做任何非幂等写操作；审计类字段更新优先走应用层或 CDC，触发器只做轻量校验
- 必须写表时，用
WITH (UPDLOCK, READPAST)降低锁冲突，但要注意READPAST会跳过被锁行，不适用于强一致性场景
触发器性能突然变差，90% 是这三件事没做
触发器是隐式执行的，容易被当成“免费午餐”。一旦在高频表（如订单流水）上加了含 JOIN、子查询、远程服务器调用的触发器，TPS 直接腰斩。
实操建议：
- 触发器体内部禁止出现
SELECT ... FROM linked_server...或OPENQUERY，网络延迟和连接池耗尽会拖垮主事务 - 所有 JOIN 必须确保关联字段有索引，特别是
INSERTED和业务表的连接字段；没索引时 SQL Server 可能对INSERTED做哈希匹配，小数据看不出问题，批量导入时 CPU 瞬间拉满 - 用
SET NOCOUNT ON开头——否则每条语句返回的 “X rows affected” 消息会加重网络开销，尤其 ORM 批量操作时
真正难的不是写触发器，是判断“这事到底该不该放触发器里做”。日志记录、状态同步、跨系统通知，这些看着简单的事，放到触发器里就容易变成线上事故的定时炸弹。
