SQL 如何实现“软删除”字段并在所有查询中自动过滤

不能只加 is_deleted 字段，因易漏过滤、污染sql、ORM绕过；应结合视图封装、ORM全局拦截、原子化删/恢复操作及跨表一致性处理。

为什么不能只加一个 is_deleted 字段就完事

加个 is_deleted 布尔字段是软删除最直观的做法，但直接裸用会导致所有业务查询都得手动写 WHERE is_deleted = false。漏写一次，逻辑就出错；新同学接手容易忽略；ORM 层可能绕过这个约束。更麻烦的是，硬编码过滤条件会污染业务 SQL，让可维护性直线下降。

postgresql / mysql 8.0+ 推荐用视图封装基础表

把原始表（比如 users）设为私有，只对外暴露一个视图 v_users，视图定义里固定加上软删除过滤：

CREATE VIEW v_users AS select * FROM users WHERE is_deleted = false;

后续所有业务查询都查 v_users，不用再操心过滤。注意两点：

• is_deleted 字段类型建议用 Boolean（PG）或 TINYINT(1)（MySQL），避免用字符串导致索引失效
• 视图不支持直接 INSERT/UPDATE，写操作仍需走原表，所以得配套封装存储过程或应用层校验
• 如果要查“含已删除数据”的管理后台，单独建 v_users_all 视图，避免混用

ORM 层（如 Django、laravel、mybatis）必须统一拦截查询

数据库层无法强制所有客户端走视图，尤其当多个服务共用同一库时。这时 ORM 是最后一道防线：

• django：重写 QuerySet 的 get_queryset()，在 Manager 中默认加 Filter(is_deleted=False)
• Laravel：在模型中定义 boot() 方法，用 Static::addGlobalScope() 注入全局作用域
• MyBatis：用 Interceptor 拦截 StatementHandler，对未显式包含 is_deleted 的 SELECT 语句自动追加条件
• 关键点：全局作用域/拦截器必须可关闭（比如加参数 withTrashed()），否则连回收站功能都做不了

DELETE 和 RESTORE 操作必须原子且带审计

软删除不是 UPDATE 一行那么简单。真实场景需要：

• UPDATE 同时更新 is_deleted、deleted_at、deleted_by 字段，三者缺一不可
• 恢复操作（restore）不能只改 is_deleted，还要清空 deleted_at 和 deleted_by，否则时间戳和操作人信息会残留
• 所有软删/恢复操作建议走存储过程或事务函数，防止应用层部分更新失败导致状态不一致
• 千万别用 TRIGGER 自动填充 deleted_at——MySQL 的 BEFORE UPDATE 触发器无法可靠捕获当前时间，PG 虽支持但增加调试复杂度

最易被忽略的其实是「跨库关联」：当 orders 表软删除了，但 order_items 表没同步处理，JOIN 查询就会漏数据。这类场景必须靠外键约束 + 应用层级联逻辑兜底，没有银弹。