SQL JOIN条件丢失的根源在于ON与WHERE混用、JOIN类型误选、NULL值处理不当及隐式类型转换；正确做法是关联和右表筛选条件写ON、全局过滤写WHERE，多租户需加tenant_id，NULL用COALESCE处理，字段类型须显式统一。
SQL JOIN 时条件丢失，通常不是语法报错，而是逻辑错误——结果数据变多、重复、或意外过滤，根源往往藏在 WHERE 和 ON 的混用、JOIN 类型误选、或 NULL 处理上。
ON 和 WHERE 混用导致隐式过滤
LEFT JOIN 中，若把本该写在 ON 的关联条件错写进 WHERE，会把左表“保留行”的语义破坏掉，实际变成 INNER JOIN 效果。
例如：
错误写法（看似 LEFT，实为 INNER）：SELECT u.name, o.amount
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.status = 'paid';
这里 o.status = 'paid' 在 WHERE 中，会过滤掉所有 o.status 为 NULL（即用户无订单）的行，LEFT JOIN 失效。
正确做法： 把业务过滤条件尽量放在 ON 子句（针对右表），保持左表完整。
- 关联条件（如
u.id = o.user_id）必须写在 ON - 右表的筛选条件（如
o.status = 'paid'）也应写在 ON，尤其在 LEFT/RIGHT JOIN 中 - 只有真正需要全局过滤的条件（如
u.created_at > '2024-01-01'）才放 WHERE
JOIN 类型选择不当，掩盖了条件缺失
用 INNER JOIN 却没写 ON 条件？多数数据库直接报错。但更隐蔽的是：写了 ON，却漏掉了关键字段，比如只连了 user_id，却忘了租户 ID tenant_id，导致跨租户数据混入。
常见疏漏场景：
- 多租户系统中，JOIN 时漏加
AND a.tenant_id = b.tenant_id - 历史表有分区键（如
dt），JOIN 未对齐日期，造成重复或遗漏 - 复合主键表 JOIN 只匹配部分字段，例如只连
order_id，忽略line_number
NULL 值让等值条件“静默失效”
JOIN 条件是 ON a.code = b.code，但任一表的 code 字段含 NULL —— 这些行不会被关联上，因为 NULL = NULL 返回 UNKNOWN，不成立。
这不是 bug，是 SQL 标准行为。容易误以为“条件写了，怎么没连上？”
- 检查关联字段是否有 NULL：用
SELECT COUNT(*) FROM t WHERE col IS NULL - 如需把 NULL 当作相同值处理，可改用
COALESCE(a.code, '') = COALESCE(b.code, '')（注意空字符串是否语义安全） - 更稳妥的方式是提前清洗：在 JOIN 前用 WHERE 排除 NULL，或用 LEFT JOIN + COALESCE 补默认值
隐式类型转换引发意外不匹配
当 JOIN 字段类型不一致（如 user_id INT vs user_id VARCHAR），数据库可能自动转类型，但转换规则因引擎而异：MySQL 可能截断字符串，PostgreSQL 则直接报错，而 SQL Server 可能静默转成 float 导致精度丢失。
