唯一可靠实现软删除自动转存的方式是instead of delete触发器，因其能阻止物理删除、在同事务内完成归档插入与软删标记更新；after delete因数据已丢失而不可靠，易致数据彻底消失。
SQL Server 中唯一能可靠实现“软删除自动转存”的方式，是用 INSTEAD OF DELETE 触发器，而不是 AFTER DELETE 或 BEFORE DELETE（后者不存在）。 因为只有 INSTEAD OF DELETE 能真正阻止物理删除发生，让你有完整窗口读取 deleted 表、写归档表、再执行软删标记 —— 三步全在同一个事务内可控。
为什么不能用 AFTER DELETE？
AFTER DELETE 触发器运行时，原表数据已经物理消失，deleted 表虽存在，但你无法再安全地 UPDATE 原表（比如设 IsDeleted = 1），因为那行记录已不在了。更糟的是：如果触发器里尝试 INSERT 归档，而归档表又因约束或权限失败，事务回滚后，数据就真丢了，没留下任何痕迹。
- 现象：DELETE 语句成功返回，但原表查不到数据，归档表也没记录 → 数据彻底丢失
- 根本原因：
deleted表只读、无索引，且生命周期仅限触发器作用域；它不是备份表，也不是日志镜像 - 对比：
INSTEAD OF DELETE下，原表行仍在，deleted表可 JOIN，UPDATE 安全，INSERT 归档也稳
INSTEAD OF DELETE 触发器里必须做哪几件事？
缺一不可。顺序和写法直接影响是否可维护、是否被 ORM 拦截报错。
- 开头必须加
SET NOCOUNT ON：否则 Entity Framework 等 ORM 会收到额外结果集，误判为多结果集查询而抛异常 - 先 INSERT 到归档表：用
SELECT * FROM deleted，但注意归档表字段要与deleted结构对齐；建议显式列出字段，避免未来原表加列导致插入失败 - 再 UPDATE 原表软删标记：必须用
INNER JOIN deleted，不能只靠 WHERE id IN (SELECT id FROM deleted)，否则大表性能差，且可能漏更新（如复合主键） - 归档表的
DeletedAt和DeletedBy字段，推荐用GETDATE()和SUSER_SNAME()，不依赖应用传值，防绕过
容易踩的坑：归档表建在哪？怎么查还原？
归档表不是放哪儿都行。它和原表放在同一数据库、同一文件组，等于把鸡蛋放在一个篮子里 —— 主库损坏，归档也一起丢。还原动作本身也不该再走触发器，否则可能陷入嵌套或死循环。
- 归档表应建在独立数据库（如
ArchiveDB），最好跨磁盘存储；至少也要建在不同文件组 - 还原操作是纯 DML：直接
UPDATE Products SET IsDeleted = 0 WHERE Id = @id，不要调触发器，也不要从归档表 SELECT 后 INSERT 回原表（可能违反唯一约束） - 如果需批量还原，用临时表存 ID 列表，再
UPDATE ... FROM #temp_ids，别用WHERE Id IN (SELECT ...)，子查询在大表上易卡住 - 千万别在触发器里调用含
INSTEAD OF的存储过程 —— 默认嵌套触发器是关闭的，得手动开：sp_configure 'nested triggers', 1，但这会放大风险
最常被忽略的一点：软删除不是加个字段+触发器就完事。所有对外暴露的视图、报表 SQL、ORM 查询默认都得加 WHERE IsDeleted = 0，漏一处，逻辑删除就形同虚设。触发器只管“删”那一瞬间，管不了后续怎么读。
