INNER JOIN 本质是交集运算，只返回连接条件为 TRUE 的行，NULL = NULL 结果为 UNKNOWN 被排除；LEFT JOIN 显式保留左表所有行，右表无匹配则填 NULL；孤立行缺失常因数据本身含 NULL 或值不匹配，而非 JOIN 类型缺陷。
INNER JOIN 本质就是交集运算，它不返回孤立行不是“没实现”，而是设计如此——只要连接条件不成立，整行就被排除。
INNER JOIN 的匹配逻辑只认 TRUE，不认 NULL 或 UNKNOWN
SQL 的三值逻辑决定了：a.id = b.user_id 在任一字段为 NULL 时结果是 UNKNOWN，而 INNER JOIN 只保留判定为 TRUE 的行。
- 哪怕左表和右表的连接字段“看起来都是空”，
NULL = NULL仍是UNKNOWN，不会被当作匹配成功 - 所以
INNER JOIN实际等价于：WHERE a.id IS NOT NULL AND b.user_id IS NOT NULL AND a.id = b.user_id - 孤立行（比如订单表里
user_id为空，或用户表里id缺失）天然无法满足这个条件，直接消失
LEFT JOIN 的“保左”机制是显式语义，不是靠运气
LEFT JOIN 的行为由 SQL 标准明确定义：先输出左表每一行，再按 ON 条件尝试从右表找匹配；找不到？右表字段全填 NULL。
- 它不关心右表有没有数据，也不检查右表字段是否为
NULL——只要左表有，就一定在结果里 - 这种“强制保留”和
INNER JOIN的“严格筛选”是正交的设计选择，不是性能妥协或语法糖 - 注意：
ON子句里如果加了右表过滤（如AND b.status = 'active'），会导致部分左表行对应右表字段全为NULL，但左表行本身仍在
为什么你查不到孤立行？可能根本不是 JOIN 类型问题
有时你以为该出现的孤立行没出来，其实是因为连接字段本身含 NULL 或值不一致，而不是 INNER JOIN “故意不给”。
- 运行
SELECT COUNT(*) FROM left_table WHERE join_col IS NULL，确认左表是否有空值 - 查右表主键是否存在对应值：
SELECT COUNT(*) FROM right_table WHERE id IN (SELECT join_col FROM left_table) - 如果发现大量
NULL或值错位，说明问题出在数据质量，而非 JOIN 选型
INNER JOIN 去查“所有用户及其订单”，漏掉零订单用户就不是补个 COALESCE 能解决的——数据已经不在结果集里了。 
