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 '% %'
user_id 字段存了 ' ' 或 '\t123'，表面看是“没连上”，其实是字符串比对失败。这类问题不会报错，只会静默丢行。
