用EXISTS比COUNT(*)更安全，可避免高并发下漏判重复；需加t.id != i.id防自匹配；INSERTED是内存临时表，勿复杂JOIN；触发器不能替代唯一索引，但可处理动态业务规则；AFTER INSERT比INSTEAD OF更合适防重。
触发器里用 EXISTS 比 SELECT COUNT(*) 更安全
直接查 COUNT(*) 判断重复，容易在高并发下漏判——两个事务同时查到 0 条，然后都插入成功。用 EXISTS 配合唯一约束逻辑更稳，且能早退出。实际写法要锁定待检查的字段组合，比如业务上要求 order_no + status 不能同时为 'PENDING' 且重复：
IF EXISTS (
SELECT 1 FROM inserted i
INNER JOIN your_table t ON t.order_no = i.order_no
AND t.status = 'PENDING'
AND t.id != i.id
)
BEGIN
RAISERROR('重复的待处理订单', 16, 1);
ROLLBACK;
END
注意：必须加 t.id != i.id（假设 id 是主键），否则刚插入的记录自己会匹配上自己。
INSERTED 表不是实时“已提交数据”，别在里面做复杂 JOIN
INSERTED 是内存中的临时表，只包含本次触发的待插入行，不反映当前表的最新状态。如果在触发器里对 INSERTED 做多表 JOIN 或子查询嵌套过深，可能拖慢插入性能，甚至引发死锁。常见错误是写成：
-- ❌ 错误：JOIN 大表 + 聚合，阻塞严重 SELECT COUNT(*) FROM INSERTED i JOIN orders o ON o.user_id = i.user_id JOIN user_profiles p ON p.user_id = o.user_id
应简化为单表存在性检查，或把校验逻辑前置到应用层。若必须查关联数据，优先走带索引的字段，并限制返回行数（如 TOP 1）。
触发器无法替代唯一索引，但能处理复合业务规则
数据库原生的 UNIQUE INDEX 效率最高、最可靠，适用于字段值本身不能重复的场景（如 email）。但业务无效记录往往依赖动态条件，比如：“同一用户 24 小时内最多提交 3 条 status = 'DRAFT' 记录”。这种时间窗口+计数+状态组合，索引搞不定，就得靠触发器。此时要注意：
- 在触发器开头加
SET NOCOUNT ON，避免影响客户端对行数的判断 - 检查逻辑中涉及的时间字段（如
created_at）必须有索引，否则全表扫描代价大 - 不要在触发器里调用外部 API 或写日志表（除非日志表是 NOLOCK 查询且无事务依赖）
SQL Server 中 AFTER INSERT 触发器比 INSTEAD OF 更适合防重
用 AFTER INSERT 可以直接读 INSERTED 表，也方便回滚；而 INSTEAD OF 需手动重写 INSERT 逻辑，稍有遗漏就会丢数据。另外，AFTER 触发器能自然继承外层事务，配合 RAISERROR + ROLLBACK 就能干净中断。但要注意：
- 触发器里禁止显式开启事务（
BEGIN TRAN），否则可能和外层事务嵌套冲突 - 如果表启用了
RECURSIVE_TRIGGERS，要确认不会因 UPDATE 自身又触发同个触发器 - 测试时务必用并发脚本（如 SQLQueryStress）验证，单线程测不出竞态问题
真正难的不是写触发器，而是厘清“什么是无效”——这个定义一旦随业务变化，触发器逻辑就得同步改，而且很难覆盖所有边界，比如软删除标记、租户隔离字段、时间精度差异（GETDATE() vs SYSDATETIMEOFFSET）……这些地方最容易漏。
