LEFT JOIN中ON决定右表匹配逻辑，WHERE在JOIN后过滤；ON中放右表条件可保留左表空行，WHERE中则导致“变INNER”；COUNT(字段)跳过NULL，COUNT(*)不跳；多表JOIN时ON不能跨表引用；右表无索引是性能瓶颈主因。
LEFT JOIN 返回空值时，ON 条件和 WHERE 条件的区别在哪
很多人发现加了 LEFT JOIN，结果却“变 INNER 了”，其实是把过滤条件错写在 WHERE 里。一旦 WHERE 中出现对右表字段的非空判断（比如 WHERE t2.status = 'active'），数据库会先完成 JOIN，再筛行——这时候右表为 NULL 的左表记录就被干掉了。
正确做法是把右表的过滤逻辑挪到 ON 子句里：
SELECT u.id, u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'
这样即使用户没支付过订单，u 行仍保留，o.amount 为 NULL。
-
ON决定“哪些右表行能连上来”，影响 JOIN 结果结构 -
WHERE是对最终结果集的筛选，发生在 JOIN 之后 - 如果右表有多个匹配行，
ON中的额外条件也会影响匹配数量（比如只连最近一笔有效订单）
LEFT JOIN 后 COUNT(*) 和 COUNT(右表字段) 差出一倍？
常见错觉：用 COUNT(*) 统计左表关联后的“总记录数”，结果比左表原始行数还多——说明右表存在一对多关系，但你没意识到 LEFT JOIN 会把左表一行“撑开”成多行。
想统计每个用户的订单数，别写 COUNT(*)，而要用 COUNT(o.id) 或 COUNT(o.user_id)，因为 NULL 不参与计数：
SELECT u.id, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id
注意：COUNT(o.id) 返回 0 对应无订单用户；COUNT(*) 在 GROUP BY 下返回的是分组内行数（含 NULL 行），容易误导。
- 右表字段带
NULL时，COUNT(字段)自动跳过，COUNT(*)不跳 - 若需区分“无关联”和“关联但字段为空”，得配合
COALESCE或显式判空 - 聚合前没
GROUP BY左表主键？大概率得到意外的单行汇总
多个 LEFT JOIN 嵌套时，后一个 JOIN 的 ON 依赖前一个结果吗
不依赖。SQL 标准中，每个 JOIN 的 ON 只能引用它直接连接的两张表（或其别名），不能跨过中间表引用更早的表字段——至少在 PostgreSQL、MySQL 8.0+、SQL Server 中如此。例如下面写法是错的：
SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN items i ON o.id = i.order_id AND u.level > 5 -- ❌ u.level 不在 i/o 范围内
如果真要基于左表状态控制后续 JOIN，得用子查询或 CTE 拆开逻辑：
WITH qualified_users AS ( SELECT id FROM users WHERE level > 5 ) SELECT u.id, o.amount, i.name FROM qualified_users u LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN items i ON o.id = i.order_id
- 别名作用域严格按 JOIN 顺序生效，不是“全局可见”
- MySQL 5.7 允许部分跨表引用，但属非标准行为，迁移时易出错
- 用 CTE 或子查询虽多写几行，但语义清晰、各数据库兼容性好
LEFT JOIN 性能突然变慢，可能卡在哪儿
最常被忽略的是右表缺少索引。当左表 10 万行、右表 50 万行，没索引的 ON 字段会导致嵌套循环全表扫描，复杂度接近 O(n×m)。
检查执行计划（EXPLAIN）时重点看右表是否走了 key，以及 rows 是否远超预期。优化方向很明确：
- 确保
ON中右表字段建了索引（如orders(user_id)） - 如果
ON含多个字段（如ON a.x = b.x AND b.y = 'val'），考虑联合索引(x, y) - 避免在
ON中对右表字段做函数操作（如ON u.id = CAST(o.user_id AS SIGNED)），索引失效 - PostgreSQL 用户注意：
LEFT JOIN ... WHERE right_table.col IS NULL这种“查找未匹配项”场景，有时用NOT EXISTS更快
空集本身不拖慢查询，慢的是为了找空集不得不扫完整张右表。
