ON 和 WHERE 有本质区别：ON 在 JOIN 阶段生效，WHERE 在 JOIN 完成后过滤；右表筛选条件必须写在 ON 中，否则 LEFT JOIN 会退化为 INNER JOIN。
JOIN 条件写在 ON 还是 WHERE？差别很大
很多人把过滤条件随手塞进 WHERE，结果发现 LEFT JOIN 变成了隐式 INNER JOIN。根本原因在于：SQL 执行顺序中，ON 在 JOIN 阶段生效，而 WHERE 是在 JOIN 完成后才过滤——一旦 WHERE 对右表字段加了非空限制（比如 WHERE b.status = 'active'），所有右表为 NULL 的左表记录就被干掉了。
实操建议：
- 右表的筛选条件必须写在
ON子句里（如LEFT JOIN orders b ON a.id = b.user_id AND b.status = 'active'） -
WHERE仅用于左表或最终结果集的全局过滤 - 用
EXPLAIN看执行计划，确认实际驱动表和是否用了索引
多表 JOIN 时别名混乱导致列歧义
三张表都含 id、created_at，SELECT 列没加表前缀，轻则查询报错 Column 'id' in field list is ambiguous，重则逻辑出错却无提示——尤其 ORM 自动生成 SQL 或视图嵌套时更隐蔽。
实操建议：
- 所有 SELECT 字段显式带别名，例如
a.id AS user_id, b.id AS order_id - 避免
SELECT *，特别是跨库或表结构可能变动的场景 - 在复杂查询中，给每张表分配简短但含义明确的别名（如
u、o、i），并在注释里说明
JOIN 顺序影响可读性与优化器决策
MySQL 5.7+ 会自动重排 JOIN 顺序，但 PostgreSQL 和 SQL Server 更依赖书写顺序；更重要的是人脑阅读时，从“主实体”开始逐层关联才符合业务直觉。把日志表放在最前面、用户表夹在中间，别人看一眼就懵。
实操建议：
- 按业务主次排列：主表（如
users）→ 关联主数据（如departments）→ 关联附属信息（如user_logs） - 避免在单个查询里混用 INNER 和 OUTER JOIN，除非有明确的层级依赖
- 超过 4 张表 JOIN 时，优先考虑拆成子查询或 CTE，用命名表达意图（如
WITH active_orders AS (...)）
NULL 值传播让 JOIN 结果难推理
LEFT JOIN 后右表字段全为 NULL，再用这些字段参与计算或比较（比如 COALESCE(b.amount, 0) > 100）看似安全，但若后续加了 WHERE b.category = 'vip' 却忘了它会过滤掉 NULL 行，结果就悄然缩水。这种问题在线上跑一周才被报表对不上发现。
实操建议：
- 对所有可能为 NULL 的 JOIN 字段，在计算或比较前做显式判断，而不是依赖默认值兜底
- 在 WHERE 中涉及右表字段时，始终检查是否允许 NULL，必要时补上
OR b.category IS NULL - 用
IS NULL/IS NOT NULL替代= NULL—— 后者永远不成立
