为何SQL中INNER JOIN会自动忽略掉关联不上的孤儿数据

INNER JOIN只返回匹配成功的行，因其语义本质是交集运算，要求连接条件为TRUE；LEFT JOIN则强制保留左表所有行，右表无匹配时填NULL。

INNER JOIN 会自动忽略孤儿数据，不是它“选择忽略”，而是它的语义定义就是只返回匹配成功的行——没匹配上，就不在结果里。

INNER JOIN 的本质是交集运算

它等价于逻辑上的「且」关系：t1.id = t2.ref_id 必须为 TRUE，该行才保留。SQL 的三值逻辑中，NULL = anything 永远返回 UNKNOWN，而 UNKNOWN ≠ TRUE，所以整行被排除。

常见表现：

• 左表有 1000 行，INNER JOIN 后只剩 620 行 → 那 380 行要么 t1.id 为 NULL，要么 t2.ref_id 不存在或为 NULL
• 订单表里 user_id 是 '0' 或 'unknown' 字符串，而用户表 id 是整型 → 类型不一致导致隐式转换失败，匹配不上

为什么 LEFT JOIN 能保留这些行

LEFT JOIN 的语义是「保左」：先取左表每一行，再按 ON 条件去右表找匹配；找不到？右表字段全填 NULL，但左表那行还在。

关键区别在于：INNER JOIN 关注「是否成立」，LEFT JOIN 关注「是否保留」。

实操建议：

• 想查哪些订单没关联到用户：用 LEFT JOIN + WHERE t2.id IS NULL
• 别在 LEFT JOIN 的 WHERE 里写 t2.status = 'active'，否则会把 t2.id IS NULL 的行也过滤掉，退化成 INNER JOIN
• 若业务上允许 ref_id 为空，又想保留左表记录，必须换 LEFT JOIN，而不是硬改 ON 条件

排查孤儿数据到底出在哪张表

不能只猜，得验证：

• 查左表空值：SELECT COUNT(*) FROM t1 WHERE id IS NULL
• 查右表缺失值：SELECT COUNT(*) FROM t2 WHERE id NOT IN (SELECT ref_id FROM t1 WHERE ref_id IS NOT NULL)
• 检查类型是否一致：SELECT pg_typeof(t1.id), pg_typeof(t2.ref_id)（PostgreSQL）或查 INFORMATION_SCHEMA.COLUMNS（MySQL）
• 注意不可见字符：SELECT ref_id, LENGTH(ref_id), HEX(ref_id) FROM t1 WHERE ref_id LIKE '% %'

真正容易被忽略的，是误把数据质量问题当成 JOIN 类型问题——比如 user_id 字段存了 ' ' 或 't123'，表面看是“没连上”，其实是字符串比对失败。这类问题不会报错，只会静默丢行。