逻辑删除需在所有查询中显式过滤is_deleted=0，否则会查出脏数据；应通过视图、ORM拦截或索引优化强制约束，并注意JOIN、分页等场景的遗漏风险。
WHERE 条件里漏加 is_deleted = 0 就会查出脏数据
逻辑删除本质是用字段标记“已删”，而非真正从磁盘移除记录。只要查询没显式过滤该标记字段，被删的数据依然参与结果集——这和业务预期完全相悖。
常见错误现象：
- 用户看到已注销账号的订单出现在个人中心
- 后台导出报表包含“已作废”的合同记录
-
COUNT(*)统计总数时比实际有效数据多出一截
解决方式不是靠开发自觉加条件，而是强制约束：
- 所有业务查询必须显式带上
is_deleted = 0（或对应字段名，如deleted_at IS NULL） - 考虑在视图层封装：建一个
v_user_active视图，内部已过滤is_deleted = 0，业务代码只查视图 - ORM 层可配置全局软删除拦截（如 MyBatis-Plus 的
@TableLogic、Laravel 的SoftDeletestrait），但要注意它不作用于原生 SQL 或跨库 JOIN
SELECT * 在逻辑删除表上永远是危险操作
哪怕只是临时查几条数据调试，SELECT * 也会把 is_deleted = 1 的记录一起捞出来，极易误导判断。
更隐蔽的问题是索引失效：
- 如果表有复合索引
(status, created_at)，但查询条件只写WHERE is_deleted = 0，MySQL 可能无法高效利用该索引 - 推荐为逻辑删除字段单独建索引，尤其是高删除率场景：
CREATE INDEX idx_is_deleted ON orders(is_deleted); - 注意：PostgreSQL 对
IS NULL类型的删除标记（如deleted_at）索引效果更好，而 MySQL 对= 0/1更友好
JOIN 时逻辑删除字段容易被忽略
多表关联时，只在主表加 is_deleted = 0 不够——关联表里的“已删”记录仍会拖入结果，造成数据膨胀或统计偏差。
典型场景：
- 查“用户订单列表”，
users表加了is_deleted = 0，但orders表没加 → 查出用户本人有效，但订单是已取消的 - LEFT JOIN 配合逻辑删除字段时，ON 条件里若不写
o.is_deleted = 0，会导致右表“假空值”（其实是匹配到了已删记录，但被 WHERE 过滤后表现为 NULL）
建议写法：
SELECT u.name, o.order_no FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.is_deleted = 0 WHERE u.is_deleted = 0;
分页 + 逻辑删除 = 数据跳变风险
用 LIMIT offset, size 分页时，若中间有记录被逻辑删除，下一页可能跳过本该出现的记录，或重复出现上一页末尾的记录。
原因很简单：删除操作改变了满足 is_deleted = 0 的行序，但 OFFSET 是按物理顺序算的。
- 例如第 1 页取前 10 条（ID 1–10），其中 ID=5 被逻辑删除；第 2 页
LIMIT 10, 10实际跳过的是 ID 1–10 中剩下的 9 条 + ID=5，导致 ID=11 被跳过 - 更稳的方式是用游标分页：
WHERE id > ? AND is_deleted = 0 ORDER BY id LIMIT 10 - 注意：游标字段必须是唯一且单调的（如自增主键或创建时间），不能用
created_at（可能重复）
