很多开发者碰到这种情况时，第一反应往往是“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'，表面看是“没连上”，其实是字符串比对失败。这类问题不会报错，只会静默丢行。
