inner join天然不返回null匹配行，因其仅保留on条件判定为true的行，而null参与的等值比较（如t1.id = t2.ref_id）在sql三值逻辑中恒为unknown，不满足true，故整行被排除。
INNER JOIN 为什么天然不返回 NULL 匹配行
因为 INNER JOIN 只保留 ON 条件判定为 TRUE 的行，而任何涉及 NULL 的等值比较（如 t1.id = t2.ref_id）在 SQL 三值逻辑中结果都是 UNKNOWN，不是 TRUE，所以整行被排除。这不是“忽略”，是语义强制——它本就不该出现。
常见表现：
- 左表有 1000 行，
INNER JOIN后只剩 620 行 → 剩余 380 行中，至少有一侧关联字段为NULL - 查右表发现“明明存在”的记录，但
ref_id是NULL或含不可见字符（如'\t123'），导致比对失败 -
NULL = NULL仍是UNKNOWN，不会被当作匹配成功
LEFT JOIN 后右表字段全为 NULL，到底是没连上，还是连上了但数据是 NULL
关键看右表主键是否为 NULL。如果 u.id IS NULL，说明根本没连上；如果 u.id 有值但 u.name IS NULL，才是右表本身数据缺失。
验证写法：
SELECT o.id, u.id AS user_id, u.name FROM orders o LEFT JOIN users u ON o.user_id = u.id
排查建议：
- 先查左表空值：
SELECT COUNT(*) FROM orders WHERE user_id IS NULL - 再查右表缺失值：
SELECT COUNT(*) FROM users WHERE id NOT IN (SELECT user_id FROM orders WHERE user_id IS NOT NULL) - 检查类型是否一致：
SELECT DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'user_id'对比 users 表对应字段
为什么把右表条件写在 WHERE 里会让 LEFT JOIN 退化成 INNER JOIN
执行顺序是 FROM → ON → JOIN → WHERE。WHERE 在连接完成后才执行，此时未匹配行的右表字段全是 NULL，WHERE t2.status = 'active' 对 NULL 判定为 FALSE，整行被过滤。
错误 vs 正确：
- ❌
LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'→ 没匹配或状态不符的订单全丢 - ✅
LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active'→ 用户还在，不满足状态的u.*全为NULL
真正容易被忽略的点：不是 JOIN 类型错了，而是数据本身带陷阱
比如 user_id 存的是字符串 '0' 或 ' '，而用户表 id 是整型；或者字段表面非空，实则含 BOM、零宽空格等不可见字符。这类问题不会报错，只会静默丢行。
调试时优先确认：
- 关联字段是否真为
NULL？用IS NULL判断，别用= NULL - 字段长度和十六进制值：
SELECT user_id, LENGTH(user_id), HEX(user_id) FROM orders WHERE user_id LIKE '% %' - 是否在写入阶段就该补默认值？比起每次
COALESCE(user_id, -1)，源头治理更稳、索引更有效
