软删除字段设计是通过添加deleted标志位（0为正常、1为逻辑删除）实现数据标记而非物理删除，需建索引、默认值设为0、所有查询/关联/更新操作显式过滤deleted=0，视图或ORM可封装但无法替代手动条件。
什么是软删除字段设计
软删除不是真正删掉数据，而是用一个标志位标记“已删除”状态。最常见做法是加一个 deleted 字段（类型通常为 TINYINT(1) 或 BOOLEAN），值为 0 表示正常，1 表示逻辑删除。
- 字段名不建议叫
is_deleted 或 deleted_at（除非业务明确需要记录时间）；统一用 deleted 更利于后续自动过滤逻辑复用
- 必须为该字段加索引，否则带
WHERE deleted = 0 的查询可能全表扫描
- 不要设默认值为
1，新插入数据必须默认 0，否则写入即“不可见”
手动 WHERE 过滤 deleted=0 是最直接方式
几乎所有 SQL 场景下，你都需要显式加条件：WHERE deleted = 0。它简单、可控、无隐式行为风险。
- 查询用户列表：
SELECT * FROM users WHERE deleted = 0
- 关联查询时，每个被 JOIN 的主表都要加该条件，例如：
SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE u.deleted = 0 AND o.deleted = 0
- UPDATE / DELETE 操作也需主动排除已软删除行，比如恢复某条记录：
UPDATE users SET deleted = 0 WHERE id = 123 AND deleted = 1
- 错误示范：漏写
WHERE deleted = 0 导致前端展示“已删除”的脏数据
视图封装可减少重复 WHERE 条件
如果你在多个地方反复写 WHERE deleted = 0，可以建一个只读视图来收敛逻辑：
CREATE VIEW active_users AS
SELECT id, name, email, created_at
FROM users
WHERE deleted = 0;
- 视图里不能包含
*（防止底层加字段后视图失效），必须显式列出字段
- 视图无法替代应用层校验：INSERT/UPDATE 仍需业务代码控制
deleted 值
- 某些 ORM（如 Laravel Eloquent）的全局作用域或 Django 的 Manager 本质也是类似思路——但它们运行在应用层，不是数据库层
触发器或存储过程不能替代 WHERE 过滤
有人想用触发器自动把 deleted = 1 的行从 SELECT 结果里剔除，这是行不通的。
- MySQL / PostgreSQL 不支持 SELECT 触发器
- 即便通过函数包装查询（如
SELECT * FROM get_active_users()），也会让 SQL 变得难以调试、ORM 难以适配、执行计划不稳定
- 最容易被忽略的一点：软删除的“自动过滤”永远不可能 100% 透明。只要用了 JOIN、子查询、UNION 或窗口函数，
deleted 状态就必须由开发者显式判断和处理
is_deleted 或 deleted_at（除非业务明确需要记录时间）；统一用 deleted 更利于后续自动过滤逻辑复用 WHERE deleted = 0 的查询可能全表扫描 1，新插入数据必须默认 0，否则写入即“不可见”WHERE deleted = 0。它简单、可控、无隐式行为风险。
- 查询用户列表：
SELECT * FROM users WHERE deleted = 0 - 关联查询时，每个被 JOIN 的主表都要加该条件，例如：
SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE u.deleted = 0 AND o.deleted = 0 - UPDATE / DELETE 操作也需主动排除已软删除行，比如恢复某条记录：
UPDATE users SET deleted = 0 WHERE id = 123 AND deleted = 1 - 错误示范：漏写
WHERE deleted = 0导致前端展示“已删除”的脏数据
视图封装可减少重复 WHERE 条件
如果你在多个地方反复写 WHERE deleted = 0，可以建一个只读视图来收敛逻辑：
CREATE VIEW active_users AS
SELECT id, name, email, created_at
FROM users
WHERE deleted = 0;
- 视图里不能包含
*（防止底层加字段后视图失效），必须显式列出字段
- 视图无法替代应用层校验：INSERT/UPDATE 仍需业务代码控制
deleted 值
- 某些 ORM（如 Laravel Eloquent）的全局作用域或 Django 的 Manager 本质也是类似思路——但它们运行在应用层，不是数据库层
触发器或存储过程不能替代 WHERE 过滤
有人想用触发器自动把 deleted = 1 的行从 SELECT 结果里剔除，这是行不通的。
- MySQL / PostgreSQL 不支持 SELECT 触发器
- 即便通过函数包装查询（如
SELECT * FROM get_active_users()），也会让 SQL 变得难以调试、ORM 难以适配、执行计划不稳定
- 最容易被忽略的一点：软删除的“自动过滤”永远不可能 100% 透明。只要用了 JOIN、子查询、UNION 或窗口函数，
deleted 状态就必须由开发者显式判断和处理
*（防止底层加字段后视图失效），必须显式列出字段 deleted 值 deleted = 1 的行从 SELECT 结果里剔除，这是行不通的。
- MySQL / PostgreSQL 不支持 SELECT 触发器
- 即便通过函数包装查询（如
SELECT * FROM get_active_users()），也会让 SQL 变得难以调试、ORM 难以适配、执行计划不稳定 - 最容易被忽略的一点：软删除的“自动过滤”永远不可能 100% 透明。只要用了 JOIN、子查询、UNION 或窗口函数，
deleted状态就必须由开发者显式判断和处理
别指望数据库替你记住哪些表要过滤。每个涉及软删除的表，每次查询，都得自己写 WHERE deleted = 0——少写一次，就可能出一次生产问题。
