LEFT JOIN 查未被引用的数据本质是主表强制保留、右表字段为 NULL 即孤立数据；必须用 LEFT JOIN + WHERE 右表外键 IS NULL，避免误用 INNER/RIGHT JOIN 或额外过滤条件。
LEFT JOIN 找不到匹配行就是孤立数据
用 LEFT JOIN 查未被引用的数据，本质是让主表“强行保留”，再看关联表是否为 NULL。不是靠子查询或 NOT EXISTS，而是靠连接后留空来识别——只要右边字段是 NULL，就说明这条记录没被任何地方引用。
常见错误是写成 INNER JOIN 或漏掉 WHERE 右表.id IS NULL，结果要么全丢光，要么根本筛不出孤立项。
- 必须用
LEFT JOIN，不能用RIGHT JOIN（逻辑反了，容易绕晕） -
WHERE条件里只判断右表的主键或外键是否为NULL，别加其他过滤（否则会提前剔除本该保留的左表行） - 如果右表有多个引用点（比如订单既被发货单引用、又被发票引用），得分别查，或用
UNION合并引用来源
示例：查 users 表中没有对应 orders 的用户
假设 users.id 是主键，orders.user_id 是外键。要找出注册了但从未下单的用户：
SELECT u.id, u.name FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL;
注意这里用的是 o.user_id IS NULL，而不是 o.id IS NULL——虽然多数情况等价，但万一 orders.id 允许 NULL（极少见）或有脏数据，就会误判。优先判断外键字段本身。
- 如果
orders.user_id有索引，这个查询通常很快；没索引时可能全表扫描右表，性能差 - MySQL 8.0+ 和 PostgreSQL 都能较好优化这类
LEFT JOIN ... IS NULL，但 SQLite 对此优化较弱，大数据量时慎用 - 别在
WHERE里写o.status = 'paid'这类条件——它会让LEFT JOIN退化成INNER JOIN效果
遇到 WHERE 条件多、JOIN 多层时怎么写
当需要排除“被任意一种业务单据引用”的数据时，容易陷入嵌套 LEFT JOIN 或反复 NOT EXISTS。更稳的方式是把所有引用来源 UNION ALL 成一张虚拟引用表，再单次 LEFT JOIN：
SELECT u.id, u.name FROM users u LEFT JOIN ( SELECT user_id FROM orders UNION ALL SELECT user_id FROM comments UNION ALL SELECT user_id FROM favorites ) refs ON u.id = refs.user_id WHERE refs.user_id IS NULL;
比写三个 LEFT JOIN 更清晰，也避免因某张引用表为空导致连接失效。
-
UNION ALL比UNION快，因为不排重——我们只关心“有没有引用”，不关心引用几次 - 如果某张引用表字段名不统一（比如
customer_id而非user_id），必须在子查询里用AS user_id显式别名 - PostgreSQL 支持
LATERAL，但此处没必要上复杂语法；简单场景坚持用UNION ALL子查询最稳妥
NULL 和空字符串、0 值混淆导致漏判
孤立数据判定依赖 IS NULL，但实际业务中常有人把外键设成默认 0 或空字符串，而非 NULL。这时 LEFT JOIN 仍会匹配到“假记录”，导致 WHERE ... IS NULL 筛不出东西。
先确认外键字段是否真允许 NULL、且业务写入时确实写了 NULL：
- 查表结构：
DESCRIBE orders;或\d orders（PostgreSQL），看user_id列的Null标记是不是YES - 查脏数据：
SELECT COUNT(*) FROM orders WHERE user_id = 0 OR user_id = ''; - 修复方式不是改查询，而是补数据或改约束——让无效引用真正变成
NULL，否则所有基于IS NULL的逻辑都会失效
外键字段值不规范，是这类查询跑不出预期结果的最常见原因，比语法错误还难排查。
