LEFT JOIN后主表数据“消失”主因是WHERE中误用字典表字段条件，导致NULL行被过滤；应将字典表筛选条件移至ON子句，同时排查NULL值、类型不一致及链式JOIN依赖NULL字段等问题。
LEFT JOIN字典表时WHERE里写了字典字段就丢数据
主表数据“消失”，八成是因为你在WHERE里对字典表字段加了条件，比如WHERE dict.status = 'enabled'。LEFT JOIN本该保留主表所有行，但WHERE会在连接完成后执行——此时字典表没匹配上的行，对应字段全是NULL，而NULL = 'enabled'判定为FALSE，整行被过滤掉，效果等同于INNER JOIN。
实操建议：
- 把字典表的业务筛选条件（如
dict.type = 'user_role'、dict.is_deleted = 0）全部挪到ON子句，用AND连接 - 只把真正需要全局过滤的条件留在
WHERE，比如主表自身的main.created_at > '2026-01-01' - 调试时先
SELECT *，观察字典表字段是否批量为NULL——这是匹配失败或条件错放的明确信号
关联字段含NULL导致匹配静默失败
字典表的code或id字段如果有NULL值，哪怕主表对应字段也有NULL，ON main.code = dict.code也不会匹配成功。因为NULL = NULL返回UNKNOWN，不被视为TRUE，该行直接被排除。
实操建议：
- 查一下：
SELECT COUNT(*) FROM dict_table WHERE code IS NULL，确认是否有空值 - 若业务允许
NULL语义一致，改用COALESCE(main.code, '') = COALESCE(dict.code, '')；但注意加函数会失效索引，仅适用于小字典表或预处理后 - 更稳妥的做法是连接前清洗：在字典表上加
WHERE code IS NOT NULL，或建视图/物化临时表提前剔除无效行
类型不一致引发隐式转换，匹配结果不可靠
主表category_id是VARCHAR(10)，字典表id是BIGINT，直接写ON main.category_id = dict.id会让数据库隐式转类型。MySQL可能转成DOUBLE导致精度丢失（比如'9223372036854775807'和9223372036854775807被判相等），PostgreSQL则直接报错。
实操建议：
- 显式转换一侧：
ON main.category_id = CAST(dict.id AS VARCHAR(10))或ON CAST(main.category_id AS BIGINT) = dict.id - 优先统一源头：让字典表的
id字段类型与主表关联字段一致，避免运行时转换 - 跨库或旧系统对接时，别依赖隐式行为——它不报错，但每天差几条，对账时才暴露
多层LEFT JOIN中依赖前层NULL字段做下层关联
比如先LEFT JOIN orders ON user.id = orders.user_id，再LEFT JOIN products ON orders.product_id = products.id。如果某用户没订单，orders.product_id就是NULL，第二层ON自动失败，products字段全为NULL——这不是bug，是逻辑必然，但常被误认为“数据丢了”。
实操建议：
- 下层关联尽量直接用主表字段，例如
LEFT JOIN products ON user.preferred_product_id = products.id - 如果必须链式关联，且需兜底，可考虑
COALESCE(orders.product_id, user.fallback_product_id)，但要确保fallback字段非空且语义合理 - 避免在
ON里用ISNULL()或COALESCE()包裹多层嵌套字段，可读性差，且易掩盖真实缺失点
ON和WHERE之间那条看不见的边界——它不报错，也不警告，只悄悄删掉你本该看到的行。 
