MySQL BEFORE DELETE触发器中UPDATE常失效，根本原因是误用NEW.id（DELETE无NEW，只有OLD），必须用OLD.id作WHERE条件，否则可能全表更新或误更新；且该UPDATE可能触发递归或被版本限制阻止。
不能真正把 DELETE 转成 UPDATE，但可以在 BEFORE DELETE 中用 UPDATE 模拟软删除行为——前提是数据库支持该时机干预，且你接受它不拦截语句本身、只覆盖效果。
MySQL 的 BEFORE DELETE 触发器里 UPDATE 为什么常失效
根本原因是误用了 NEW.id：DELETE 没有 NEW，只有 OLD。触发器中必须用 OLD.id（或全部主键字段）作为 WHERE 条件，否则可能更新零行或误更新多行。
- 漏写
WHERE id = OLD.id→ 全表UPDATE，所有记录被标记为已删 - 复合主键表只写
WHERE id = OLD.id→ 忽略其他主键字段，条件不精确，可能命中错误行 - 触发器里执行的
UPDATE会再次触发BEFORE UPDATE，若该触发器又改字段，可能形成隐式递归 - MySQL 不允许在触发器中对原表做
UPDATE（某些版本报错），需确认版本是否支持（5.7+ 一般可运行，但属“非标准用法”）
SQL Server 的 INSTEAD OF DELETE 才是真替换
INSTEAD OF DELETE 是唯一能真正“替代”原操作的机制：它阻止物理删除发生，让你完全控制后续动作。此时 deleted 表可用，且生命周期仅限当前触发器作用域。
- 必须显式
UPDATE原表标记字段，如SET IsDeleted = 1 - 可顺手把
deleted表数据插入归档表，实现自动存档 - 记得加
SET NOCOUNT ON，否则部分 ORM 会因返回行数异常而报错 - 不能在触发器内调用另一个含
INSTEAD OF的存储过程，否则嵌套触发器默认关闭，需手动启用sp_configure 'nested triggers', 1
PostgreSQL 部分索引 + BEFORE UPDATE 更稳妥
PostgreSQL 原生不支持 INSTEAD OF 对普通表生效（仅视图支持），而 BEFORE DELETE 中执行 UPDATE 同样受限。更推荐的路径是：禁用 DELETE 权限，用 BEFORE UPDATE 控制 is_deleted 字段变更，并配以部分索引提升查询效率。
- 建索引：
CREATE INDEX idx_active_users ON users(id) WHERE is_deleted = false - 触发器只响应
UPDATE中is_deleted从false变true的场景，设deleted_at - 应用层禁止直接发
DELETE，DBA 用专用函数封装清理逻辑 - 外键级联完全失效，子表需单独走软删流程，不能依赖
ON DELETE CASCADE
真正容易被忽略的是：软删除后，所有关联查询、统计聚合、分页总数都得显式过滤 is_deleted = false，哪怕只是 JOIN 一张用户表，漏掉这个条件就等于暴露已删数据。触发器管不了这些，它只管“删”那一瞬间的动作。
