inner join 天然过滤 null 关联行，因 null 与任何值比较均返回 unknown，而三值逻辑中仅 true 被保留；on 条件等价于隐式添加 is not null 检查。
INNER JOIN 为什么天然过滤掉 NULL 关联行
因为 INNER JOIN 的语义就是「只保留左右表都能匹配上的记录」，它不关心字段值是否为 NULL，而是基于 ON 条件的布尔判断——而 NULL = anything 永远返回 UNKNOWN，在 SQL 的三值逻辑中，UNKNOWN 不被视为 TRUE，因此该行直接被排除。
常见错误现象：
– 左表有 100 行，右表有 50 行，但 INNER JOIN 结果只有 30 行，且你确认某些左表 id 在右表里“明明存在”，却没出来；
– 实际查右表发现那些“存在”的记录，其关联字段（比如 user_id）是 NULL，或左表对应字段也是 NULL。
- 只要
ON子句中任一参与比较的字段为NULL，整条匹配就失效 -
INNER JOIN t2 ON t1.id = t2.ref_id等价于隐式加了WHERE t1.id IS NOT NULL AND t2.ref_id IS NOT NULL - 若业务上允许
ref_id为空，又想保留左表记录，就得换LEFT JOIN，再手动WHERE t2.ref_id IS NOT NULL过滤
ON 条件里写 WHERE 逻辑会出什么问题
把本该在 WHERE 中做的过滤提前塞进 ON，尤其混用外连接时，结果常被误读。但对 INNER JOIN 来说，ON 和 WHERE 在最终结果上通常等效——只是执行顺序和可读性不同。
关键区别在于：如果 ON 中包含非关联字段的过滤（比如 t2.status = 'active'），它会在连接过程中就筛掉右表不满足的行，从而影响连接基数；而放在 WHERE 是连接完成后再筛，逻辑一致但可能错过优化机会。
- 推荐把纯关联条件（
t1.id = t2.ref_id）放ON，业务过滤（t2.deleted = 0）也放ON—— 多数数据库能更好下推谓词 - 避免在
ON里写t1.name LIKE '%abc%'这类无索引支持的模糊条件，会导致连接变慢甚至全表扫 - 当右表有千万级数据，而
t2.type = 'order'能过滤掉 95% 行，把它放进ON可显著减少中间连接量
如何验证某次 INNER JOIN 是否漏掉了预期数据
最直接的办法不是看结果，而是对比「左表全集」和「JOIN 后左表主键去重集合」的差异。
示例：你想确认 orders 表是否所有 customer_id 都能在 customers 表中找到对应记录：
SELECT customer_id FROM orders WHERE customer_id NOT IN ( SELECT id FROM customers WHERE id IS NOT NULL );
注意这个写法有陷阱：NOT IN 遇到子查询含 NULL 会整个返回空结果。更安全的是用 LEFT JOIN 找缺失：
SELECT o.customer_id FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE c.id IS NULL- 若此查询有结果，说明这些
customer_id在customers中不存在或为NULL，它们在INNER JOIN中必然消失 - 检查
orders.customer_id是否有NULL值：SELECT COUNT(*) FROM orders WHERE customer_id IS NULL
JOIN 字段类型不一致导致的静默过滤
这是最容易被忽略的无效过滤来源：字段看似能连，实则因隐式类型转换失败而永远不匹配。
典型场景：
– 左表 user_id 是 VARCHAR(32)，存的是 '123'；
– 右表 ref_user_id 是 INT，值为 123；
– 数据库可能尝试把字符串转成数字比较，但一旦遇到 'abc123' 或前导空格，转换失败即得 NULL，匹配中断。
- 用
SELECT pg_typeof(col)（PostgreSQL）或SHOW COLUMNS（MySQL）确认两边字段类型完全一致 - 避免依赖隐式转换，显式用
CAST(t1.id AS BIGINT) = t2.ref_id或函数标准化（如TRIM(t1.code) = t2.code） - 在 JOIN 前先抽样检查：
SELECT id, LENGTH(id), ASCII(SUBSTR(id,1,1)) FROM t1 LIMIT 5，看是否有不可见字符或格式异常
