on条件能提前过滤右表数据，where必须等join完成后才执行；left join中where过滤右表字段会隐式转为inner join，应将右表筛选条件移入on子句。
ON 条件能提前过滤右表数据，WHERE 不能
ON 在 JOIN 执行过程中起作用，数据库会用它决定“哪些右表行参与连接”。如果 ON 里写了 t2.status = 'paid'，优化器通常能把这个条件下推到右表扫描阶段——只读取满足状态的行，中间结果集更小。
WHERE 则必须等 JOIN 完成、临时表生成后才执行。哪怕右表有 100 万行，其中 99 万不满足 WHERE t2.status = 'paid'，这 99 万也得先连上左表、生成临时行，再被 WHERE 扔掉。
- 性能差异最明显在 LEFT JOIN + 大右表场景：ON 过滤可大幅减少连接开销；WHERE 过滤等于白连
- 索引是否生效关键看条件能否在 JOIN 前利用：
ON t2.user_id = t1.id AND t2.status = 'paid'若t2.status有索引，可能走ref或range；WHERE t2.status = 'paid'在 LEFT JOIN 下大概率退化为全表扫描后再过滤 - EXPLAIN 中看
filtered值：ON 条件常让该值变小（表示连接时已筛掉大量行）；WHERE 条件对filtered影响滞后，且往往更高
LEFT JOIN 中 WHERE 过滤右表字段 = 隐式 INNER JOIN
写 LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'paid'，逻辑上等价于先 LEFT JOIN 再删掉所有 t2.status 不为 'paid' 的行——包括 t2.status IS NULL 的行（即左表有、右表无匹配的记录）。结果就是左表“丢失”了没订单的用户，和直接写 INNER JOIN 没区别。
- 典型错误现象：
SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'—— 返回结果里压根没有o.*全为 NULL 的用户 - 真正想保留所有用户、只关联已支付订单？必须把状态条件挪进
ON：ON u.id = o.user_id AND o.status = 'paid' - 如果业务上既要保留左表全部，又要筛右表某字段非 NULL（比如只看有物流单号的订单），得用
WHERE o.tracking_no IS NOT NULL，但绝不能用WHERE o.status = 'paid'这类等值判断
INNER JOIN 中 ON 和 WHERE 看似等效，实则语义与维护风险不同
执行结果常一样，但意图和后续扩展性差很远。把 t2.deleted = 0 放 ON，是声明“只连未删除的记录”；放 WHERE，是声明“连完再筛”。前者更贴近业务本意，后者容易让人误以为可以随意改成 LEFT JOIN。
- 一旦你把查询从
INNER JOIN改成LEFT JOIN，原来在WHERE的右表条件必须立刻挪进ON，否则逻辑崩坏 - 某些引擎（如老版本 MySQL 或 Presto）不会自动重写
WHERE条件到连接阶段，导致结果或性能不一致 - 多表 JOIN 时，
ON条件若混入非关联字段（如AND t2.category = 'A'），可能让优化器放弃使用索引，尤其当t2.category无索引时
ON 中引用左表字段 ≠ 先过滤左表
LEFT JOIN t2 ON t1.id = t2.t1_id AND t1.type = 'vip' 不会筛掉非 VIP 用户——它只是说“只有 VIP 用户才尝试去连 t2”，非 VIP 用户照样出现在结果里，只是 t2.* 全为 NULL。
真要只查 VIP 用户，得用 WHERE t1.type = 'vip'，这个动作发生在 JOIN 之后、结果输出前，但它是对左表的最终筛选，不影响连接逻辑。
- 混合需求（VIP 用户 + 已支付订单）应拆开：
ON t1.id = t2.t1_id AND t2.status = 'paid'+WHERE t1.type = 'vip' - 别在
ON里塞复杂计算或函数（如DATE(t2.created_at) = '2025-01-01'），这会让右表索引失效，且无法下推 - 最易被忽略的是 NULL：ON 中的条件若涉及右表可能为 NULL 的字段（如
t2.amount > 100），而该字段又没索引，整个连接可能慢得不可接受
