逻辑删除字段必须放在JOIN的ON子句而非WHERE中，否则LEFT JOIN会拉出已删除记录，INNER JOIN可能因优化器行为导致过滤失效；多表连接时各表逻辑删除条件需独立写入对应ON子句，视图或ORM框架中亦需显式处理。
JOIN后WHERE条件没生效，逻辑删除字段被忽略
直接在JOIN语句后加WHERE is_deleted = 0看似合理，但若右表（被连接表）有逻辑删除记录，而连接条件本身不带过滤，就会导致左表记录被“意外拉出”已删除的右表数据——尤其在LEFT JOIN中更隐蔽。例如：LEFT JOIN orders ON u.id = o.user_id，即使o.is_deleted = 1，只要u.id匹配，这条订单仍会出现在结果里，只是字段为NULL或默认值，容易误判。
正确做法是把逻辑删除判断放进ON子句，而非WHERE：
SELECT u.name, o.order_no FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.is_deleted = 0;
-
ON里的o.is_deleted = 0决定“哪些订单能参与连接”，未满足的订单直接不参与匹配，o.order_no自然为NULL -
WHERE只用于最终结果过滤（如筛掉u.status = 'inactive'），不能替代连接逻辑控制 - 若用
INNER JOIN，ON和WHERE效果等价，但统一写在ON更利于逻辑复用和可读性
多表JOIN时各表逻辑删除字段必须独立控制
三个及以上表连接时，每个被连接表的逻辑删除状态需单独在对应ON条件中声明，不能只靠最外层WHERE统控。否则会出现“A连B正常，B连C却带出已删除C记录”的断裂。
错误写法：
SELECT u.name, o.order_no, i.item_name FROM users u INNER JOIN orders o ON u.id = o.user_id INNER JOIN items i ON o.id = i.order_id WHERE o.is_deleted = 0 AND i.is_deleted = 0;
问题：当orders中某条记录is_deleted = 1，但items里恰好有order_id指向它且i.is_deleted = 0，该item仍可能因INNER JOIN强制匹配而出现（取决于优化器执行顺序）。
正确写法：
SELECT u.name, o.order_no, i.item_name FROM users u INNER JOIN orders o ON u.id = o.user_id AND o.is_deleted = 0 INNER JOIN items i ON o.id = i.order_id AND i.is_deleted = 0;
- 每张业务表的
is_deleted字段必须绑定到其对应的ON条件中 - 若某表无逻辑删除字段（如
users），则无需添加；但若未来加上，就得同步补AND u.is_deleted = 0 - 别依赖
WHERE兜底——JOIN执行顺序和优化器行为可能导致预期外结果
使用视图封装逻辑删除过滤时注意JOIN上下文丢失
有人会建视图如CREATE VIEW active_orders AS SELECT * FROM orders WHERE is_deleted = 0，再JOIN active_orders。这看起来干净，但隐患在于：视图定义脱离了JOIN上下文，无法动态响应连接时的参数（比如按租户ID过滤），且部分数据库（如MySQL 5.7）对视图+JOIN的优化较差，可能全表扫描后再过滤。
更稳妥的方式是用CTE或内联子查询明确约束范围：
WITH active_orders AS ( SELECT * FROM orders WHERE is_deleted = 0 AND tenant_id = ? ) SELECT u.name, o.order_no FROM users u INNER JOIN active_orders o ON u.id = o.user_id;
- CTE中的
tenant_id = ?能随外部查询参数实时生效，视图做不到 - 避免嵌套视图——一旦
active_orders视图又被其他视图引用，逻辑删除条件容易被覆盖或忽略 - 如果必须用视图，确保其定义包含所有必要过滤字段，并在JOIN时仍显式加
ON ... AND v.tenant_id = ?
ORM框架中JOIN与逻辑删除的常见错配
像MyBatis、Hibernate这类框架，若实体类标注了@Where(clause = "is_deleted = 0")，它只对单表查询生效；一旦写JOIN SQL，这个注解默认不注入到ON条件里，导致关联表数据未过滤。
解决方案分场景：
- MyBatis XML中，必须手动在
<join>或ON里写AND o.is_deleted = 0，不能指望全局拦截 - Hibernate JPQL不支持在
JOIN子句中加条件，得改用原生SQL或Criteria API构造带ON过滤的Join<Order> - Spring Data JPA的
@Query自定义SQL里，同样要显式写出AND逻辑删除判断，框架不会自动补
最容易被忽略的是：同一个实体在不同查询场景下，有的走单表@Where，有的走JOIN，逻辑不一致会导致数据口径混乱。上线前务必用EXPLAIN确认生成的SQL是否真带了is_deleted = 0在ON里。
