SQL 逻辑删除对查询的影响

逻辑删除需在所有查询中显式过滤 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 的 SoftDeletes trait），但要注意它不作用于原生 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（可能重复）

逻辑删除不是开关，是整套查询契约。最常被绕过的不是技术方案，而是“每次写 SQL 都要多看一眼删除标记”这件事本身。