最可靠方式是直接从Deleted表SELECT明确定义的主键列；因SQL Server不保证Deleted表行序，依赖顺序（如TOP 1）会导致结果随机、不可重现，多行删除时易漏数据或错配，且Deleted表只读、不可更新。
直接从 Deleted 表里 SELECT 主键列是最可靠的方式，前提是原表有明确定义的主键（或至少一个唯一约束列）。
为什么不能只靠行序取 Deleted 表的第一行
很多人误以为 Deleted 表的行顺序和 DELETE 语句中 WHERE 条件匹配的顺序一致——这是错的。SQL Server 不保证 Deleted 表的物理顺序，尤其在并行执行、批量删除或带索引跳过扫描时，顺序完全不可控。
- 用
SELECT TOP 1 id FROM Deleted ORDER BY (SELECT NULL)强行取值，结果随机且不可重现 - 在触发器里对多行删除（如
DELETE FROM Orders WHERE status = 'cancelled'）做单行假设，必然漏数据或错配 - 没有主键的表，
Deleted表甚至无法安全关联到业务逻辑中的“哪一行被删了”
如何安全提取被删行的主键值
核心原则：把 Deleted 当作普通表来查，只 SELECT 明确需要的主键列，不依赖其他字段或顺序。
- 单列主键（如
id）：直接写SELECT id FROM Deleted - 复合主键（如
(order_id, line_no)）：必须写全，SELECT order_id, line_no FROM Deleted - 若需写入审计日志，建议用
FOR JSON AUTO序列化整行，而不是拼字符串：SELECT (SELECT * FROM Deleted FOR JSON AUTO) AS DeletedData - 避免在触发器里做
INSERT ... SELECT *到日志表——如果日志表结构未来变更，会因列数不匹配而失败；显式列出字段更健壮
常见错误：在 AFTER DELETE 触发器里还去查原表
有人想“确认一下这行是不是真被删了”，于是写 IF EXISTS (SELECT 1 FROM OriginalTable WHERE id = @id)——这不仅多余，还可能因事务隔离级别看到残留数据（比如未提交的回滚前状态），或引发死锁。
-
Deleted表的内容是确定的：它就是刚刚被 DELETE 语句移出原表的那些行，无需二次验证 - 触发器运行在同一个事务上下文中，原表此时已不包含这些行，查它只会增加锁争用和逻辑冗余
- 如果原表有
ON DELETE CASCADE，Deleted表只含直接受影响的父表行，子表删除由另一套触发器或外键机制处理，别混在一起查
真正容易被忽略的是复合主键场景下 JOIN 条件漏写字段，或者把 Deleted 当成可 UPDATE 的表去操作——它只读，任何试图修改它的语句都会报错。
