不能靠触发器“真正替换”delete，它最多补救或拦截；mysql中before delete触发器内update常失效，根本原因是误用不存在的new.id，必须用old.id作where条件，否则可能全表更新或误更新；sql server的instead of delete才是唯一真拦截机制；postgresql和oracle更推荐禁用delete权限、用before update控制软删字段并配部分索引。
不能靠触发器“真正替换”DELETE，它最多帮你补救或拦截——但补救常失效，拦截需配合权限与设计。
MySQL 的 BEFORE DELETE 触发器里 UPDATE 为什么总不生效
根本不是语法错，而是逻辑误用：NEW.id 在 DELETE 触发器里根本不存在，只有 OLD.id 可用。漏写 WHERE id = OLD.id，UPDATE 就会变成全表更新；复合主键表只写单字段，可能命中错误行。
- 必须用
OLD引用被删行，例如：UPDATE users SET is_deleted = 1 WHERE id = OLD.id - 如果表有联合主键（如
(order_id, item_id)），WHERE 条件必须写全：WHERE order_id = OLD.order_id AND item_id = OLD.item_id - 这个
UPDATE会再次触发BEFORE UPDATE触发器，若后者又改同一字段，可能隐式递归 - MySQL 5.7+ 允许对原表做 UPDATE，但属非标准用法；8.0 某些配置下仍可能报错
Can't update table 'users' in stored function/trigger
SQL Server 的 INSTEAD OF DELETE 才是唯一能真拦截的机制
INSTEAD OF DELETE 不是“补救”，而是直接阻止物理删除发生。此时 deleted 表可用，且结构与原表一致，生命周期仅限当前触发器作用域。
- 必须显式用
UPDATE标记字段，例如：UPDATE p SET IsDeleted = 1 FROM Products p INNER JOIN deleted d ON p.Id = d.Id - 顺手把
deleted表数据插入归档表，实现自动存档：INSERT INTO Products_Archive SELECT *, GETDATE(), SUSER_SNAME() FROM deleted - 务必加
SET NOCOUNT ON，否则部分 ORM（如 Entity Framework）会因多结果集或影响行数异常而中断 - 不能在触发器内调用另一个含
INSTEAD OF的存储过程，否则嵌套触发器默认关闭，需手动启用：sp_configure 'nested triggers', 1
PostgreSQL 和 Oracle 更推荐绕开触发器硬刚 DELETE
PostgreSQL 原生不支持 INSTEAD OF 对普通表生效（仅视图支持），BEFORE DELETE 中执行 UPDATE 同样受限；Oracle 则干脆不提供 SQL 层面重写 DELETE 的能力。
- PostgreSQL 推荐：禁用
DELETE权限 +BEFORE UPDATE控制is_deleted字段变更 + 配合部分索引：CREATE INDEX idx_active_users ON users(id) WHERE is_deleted = false - Oracle 实用做法：建
BEFORE DELETE触发器直接抛错，强制走存储过程接口：RAISE_APPLICATION_ERROR(-20002, 'Direct DELETE prohibited') - 两者共性：外键
ON DELETE CASCADE对软删除完全无效，子表必须单独走软删流程 - TRUNCATE 永远绕过所有 DML 触发器，软删除设计必须明确排除该命令的使用场景
真正容易被忽略的是查询层和关联逻辑
触发器只管“删”的那一瞬间，管不了之后任何一次 SELECT、JOIN 或 COUNT(*) —— 漏一个 AND is_deleted = 0，就等于把已删数据暴露给业务。
- 所有关联查询（哪怕只
JOIN一张用户表）都得显式加过滤条件，ORM 默认全局拦截（如 MyBatis-Plus 的logic-delete）比人工写更可靠 - 统计类 SQL（如
COUNT(*)）必须改成COUNT(CASE WHEN is_deleted = 0 THEN 1 END)或类似写法，否则总数永远不准 - 索引没覆盖
is_deleted字段时，WHERE is_deleted = 0可能触发全表扫描，尤其当软删比例高、表数据量大时 - 应用层看到
DELETE FROM users WHERE id = 123返回 “1 row affected”，但数据还在——这不是失败，是软删除生效的正常表现，却极易被误判为 SQL 未执行
