软删除应使用 BEFORE DELETE 触发器中 UPDATE 标记字段（如 is_deleted=1），必须用 OLD 引用被删行、加 WHERE 精确条件，避免误更新；需手动处理外键级联、查询补 is_deleted=0 条件、索引优化及 ORM 适配。
触发器里怎么拦截 DELETE 并改成 UPDATE
SQL 触发器不能真正“阻止”或“重写”一条 DELETE 语句，但可以在执行前（BEFORE DELETE）或执行后（AFTER DELETE）做动作。软删除的正确做法是：在 BEFORE DELETE 中取消原操作，并手动更新 is_deleted 字段。
关键点在于：必须用 DELETE 的触发器逻辑覆盖掉物理删除行为，而不是等它删完再补救——那样就晚了。
- MySQL / PostgreSQL 支持
BEFORE DELETE触发器中使用NEW（实际是OLD）访问被删行，可在此处做UPDATE - SQLite 不允许在触发器里执行
UPDATE同一张表（会报no such table或死锁），得用INSTEAD OF视图替代 - SQL Server 的
INSTEAD OF DELETE是最匹配的机制，直接替换原操作
BEFORE DELETE 触发器里写 UPDATE 为什么有时不生效
常见错误是忘了加 WHERE 条件，或者误用了 NEW.id（实际该用 OLD.id）。触发器里的 OLD 才代表即将被删的那行数据。
以 MySQL 为例：
CREATE TRIGGER users_soft_delete BEFORE DELETE ON users FOR EACH ROW UPDATE users SET is_deleted = 1, deleted_at = NOW() WHERE id = OLD.id;
- 必须用
OLD.id，不是NEW.id（DELETE没有NEW） - 如果表有复合主键，
WHERE要覆盖全部主键字段，否则可能误更新多行 - 这个
UPDATE会再次触发其他触发器（比如BEFORE UPDATE），需确认是否允许嵌套
外键约束和索引对软删除的影响
物理删除会被外键级联捕获，但软删除不会自动触发 ON DELETE CASCADE。如果你依赖外键清理子表，软删除后得手动处理子表标记，否则数据状态会不一致。
-
FOREIGN KEY ... ON DELETE CASCADE对软删除完全无效，它只响应真实DELETE - 查询时所有
WHERE都得显式加上AND is_deleted = 0，漏一处就暴露已“删”数据 - 建议给
is_deleted加索引，尤其当表大、软删比例高时；否则WHERE is_deleted = 0可能全表扫描 - PostgreSQL 可用部分索引：
CREATE INDEX idx_active_users ON users(id) WHERE is_deleted = false
应用层调用 DELETE 时没反应，但数据还在
这是软删除生效的正常表现，但容易让人误以为 SQL 没执行成功。根本原因是：应用发了 DELETE FROM users WHERE id = 123，触发器把它转成了 UPDATE，返回影响行数为 1（不是 0），但数据没消失。
- 检查返回值不能只看“是否 > 0”，要结合日志或查表确认行为——
DELETE返回 1 行影响，实际是UPDATE成功了 - ORM 如 Laravel Eloquent、Django ORM 默认不识别软删除字段，需额外配置（如
softDeletes()），否则->delete()还是走物理删 - 测试时别只靠
SELECT COUNT(*)判断删没删，得查is_deleted值
软删除真正的复杂点不在触发器本身，而在于整个系统所有读写路径都得适配这个“假删真改”的契约——漏掉一个 WHERE、一个索引、一个 ORM 配置，数据就不可信了。
