最可靠方式是直接从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 的表去操作——它只读，任何试图修改它的语句都会报错。