sql server触发器中deleted表是批量结果集而非单行，误作单值处理会导致数据丢失或报错；应通过join、子查询等集合操作安全处理，避免标量赋值或in子句陷阱。
触发器里收到的 deleted 表不是单行，而是整批结果集
SQL Server 的 DML 触发器（AFTER DELETE）在批量删除时，不会为每一行触发一次，而是只触发一次，但 deleted 表里会包含所有被删的行。这是关键前提——误以为它是“逐行触发”，容易写出只处理单行的逻辑，导致漏数据或报错。
常见错误现象：SELECT @id = id FROM deleted 在批量删多行时会报错或只取到任意一行（取决于执行计划），因为 @id 是标量变量，无法承载结果集。
- 永远用
JOIN deleted或子查询方式关联操作，而不是赋值给变量 - 需要聚合统计（如删了多少条）时，用
(SELECT COUNT(*) FROM deleted)，而非@@ROWCOUNT（它反映的是触发前语句影响行数，不可靠） - 若需对每条被删记录做独立后续动作（比如写日志），必须用游标或
INSERT INTO ... SELECT批量插入，不能靠变量循环
批量 DELETE 触发器中如何安全更新关联表？
直接 UPDATE target SET status = 'deleted' WHERE id IN (SELECT id FROM deleted) 是推荐做法，但要注意：如果 deleted 行数极大（比如 10 万+），IN 子句可能触发性能问题或参数个数限制（尤其用 ORM 拼接时）。这时应改用 JOIN 写法：
UPDATE t SET t.status = 'deleted' FROM target_table t INNER JOIN deleted d ON t.id = d.id;
这种写法不依赖子查询展开，SQL Server 优化器更容易生成高效执行计划。同时避免了 IN 对 NULL 值的诡异行为（WHERE id IN (SELECT id FROM deleted) 在 deleted.id 含 NULL 时整个条件恒假）。
-
deleted表结构与原表一致，但不含计算列、IDENTITY 属性（除非显式指定） - 不要在触发器里再对原表做
DELETE或UPDATE（可能引发嵌套触发或死锁） - 若关联更新涉及多个表，优先用 CTE +
MERGE或分步UPDATE，避免一次性大事务阻塞
为什么 TRUNCATE 不会触发 AFTER DELETE 触发器？
TRUNCATE TABLE 是 DDL 操作，绕过事务日志的逐行记录机制，也不填充 deleted 表，因此任何 AFTER DELETE 或 INSTEAD OF DELETE 触发器都不会执行。这是设计使然，不是 bug。
这意味着：如果你依赖触发器做审计、级联清理或状态同步，TRUNCATE 会导致逻辑丢失。生产环境执行前务必确认是否允许跳过触发逻辑。
- 替代方案：用
DELETE TOP (N) FROM ...分批删，既可控又保触发器 - 若真需清空且必须走触发器，只能用不带 WHERE 的
DELETE FROM table_name，但要注意事务日志膨胀和锁升级风险 - MySQL 用户注意：MySQL 没有
deleted表概念，而是用OLD关键字，且TRUNCATE同样不触发BEFORE/AFTER DELETE
并发下批量 DELETE 触发器容易踩的坑
高并发场景中，两个事务几乎同时删同一组主键，触发器若没做好隔离，可能出现重复处理或丢失更新。比如都查 deleted 然后往日志表插记录，结果两条一模一样的日志。
根本原因在于触发器运行在原事务上下文中，deleted 表本身是事务私有的临时结构，但后续 INSERT/UPDATE 若没加唯一约束或排他锁，就暴露竞争窗口。
- 日志类操作：给日志表加
UNIQUE (operation_type, target_id, trigger_time)或类似组合索引，配合IGNORE/ON CONFLICT DO NOTHING（PostgreSQL）防止重复 - 状态同步类操作：用
UPDATE ... SET x = y WHERE id IN (SELECT id FROM deleted) AND current_status != 'deleted'加条件过滤，避免覆盖已有状态 - 避免在触发器里调用外部服务或长耗时逻辑——它会拖慢主 DELETE 事务，放大锁等待
deleted 是集合不是容器，事务边界和并发控制必须显式考虑。最常被忽略的是：把单行思维硬套到批量上下文，以及默认 TRUNCATE 会走触发器——这两点几乎每次上线都出问题。
