INSTEAD OF DELETE 是软删除+归档的正确起点，它能真正接管删除操作，将“删”转为“标为已删+写入归档”，依赖 deleted 表一次性完成，避免幻读、死锁及跨表一致性风险。
SQL Server 的 INSTEAD OF DELETE 才是软删除+归档的正确起点
不能靠 AFTER DELETE 或 BEFORE DELETE 实现可靠软删归档——前者物理删除已发生，后者无法阻止删除。只有 INSTEAD OF DELETE 能真正接管语句，把“删”变成“标为已删 + 写入归档”。它不依赖权限禁用或应用层补救，是数据库原生支持的拦截机制。
关键前提是：触发器必须显式处理 deleted 表（只读临时表，结构同原表，含所有被删行），且所有归档动作必须基于它，不能回查原表。
-
deleted表只在当前触发器作用域内有效，生命周期随触发器结束而销毁 - 归档 INSERT 必须与主表在**同一数据库**；跨库写入需用
dblink（PostgreSQL）或链接服务器（SQL Server），但会引入连接稳定性与事务一致性风险 - 必须加
SET NOCOUNT ON，否则 Entity Framework 等 ORM 可能因多结果集报错中断
归档逻辑必须放在 UPDATE 之后、且仅依赖 deleted 表
常见错误是先 UPDATE 标记字段，再 SELECT 原表数据归档——这会导致读到更新后的状态（如 is_deleted = 1 已生效），甚至引发死锁或幻读。正确做法是：所有归档字段直接从 deleted 表取值，一次完成。
示例（以 Products 表为例）：
CREATE TRIGGER trg_InsteadOfDelete_Products
ON Products
INSTEAD OF DELETE
AS
BEGIN
SET NOCOUNT ON;
<pre class='brush:php;toolbar:false;'>-- 步骤1：标记为软删除
UPDATE p
SET IsDeleted = 1, DeletedAt = GETDATE()
FROM Products p
INNER JOIN deleted d ON p.Id = d.Id;
-- 步骤2：归档（全部字段来自 deleted，不查原表）
INSERT INTO Products_Archive (Id, Name, Price, CreatedAt, DeletedAt, ArchivedAt, Operator)
SELECT Id, Name, Price, CreatedAt, GETDATE(), GETDATE(), SUSER_SNAME()
FROM deleted;END;
- 归档时间用
GETDATE()，不是DeletedAt字段（后者是软删标记时间，可能早于本次操作） - 若原表有计算列、默认约束或触发器，
deleted表中不含其运行结果，归档时需按需补全 - 归档表字段类型必须与
deleted表完全一致，尤其注意TIMESTAMP、TEXT、XML等易隐式转换类型
外键级联和多表关联归档得手动处理
INSTEAD OF DELETE 不会触发任何外键级联行为（如 ON DELETE CASCADE 自动失效）。如果订单表 Orders 外键指向用户 Users，用户被“删”时，订单不会自动软删——你得在触发器里显式处理。
- 子表必须已有软删字段（如
IsDeleted），否则 UPDATE 会失败 - 关联更新需用
INNER JOIN deleted显式匹配，不能靠 WHERE 子查询，否则可能漏行或误更新 - 多层关系（如
Users → Orders → OrderItems）不建议在单个触发器里递归处理，容易超时或锁表；应拆成独立存储过程 + 应用层事务控制 - 若子表无软删字段，又不能改表结构，只能记录日志并告警，由运维人工介入
硬删除通道必须保留，且不能被触发器覆盖
运维清理、GDPR 擦除、修复迁移等场景需要真实物理删除。如果所有 DELETE 都被 INSTEAD OF 拦截，这类操作就卡死。最简方案是：建一个带签名的专用存储过程，绕过触发器。
- 例如：
EXEC sp_hard_delete_Products @Id = 123, @BypassKey = 'admin@2026' - 该过程内部用
DELETE FROM Products WITH (TABLOCKX) WHERE Id = @Id，不走触发器路径 - 触发器本身不做权限判断（SQL Server 触发器内无法可靠获取调用上下文），硬删除权限应通过数据库角色严格管控
- 归档表也应定期物理清理（如分区表按
ArchivedAt分区），避免无限膨胀
真正难的不是写触发器，而是让所有业务代码、ORM 查询、报表 SQL、ETL 脚本都默认过滤 IsDeleted = 0；漏一处，就等于没软删。视图封装和部分索引（WHERE IsDeleted = 0）比依赖开发自觉更可靠。
