LEFT JOIN未保留左表全部数据的主因是WHERE中对右表字段的非空限制会过滤NULL行，等效INNER JOIN；正确做法是将右表条件移至ON子句。
LEFT JOIN为什么没保留左表全部数据
常见错误是误以为只要写了 LEFT JOIN，左表就一定全量返回——其实只要 WHERE 条件里对右表字段做了非空限制（比如 WHERE t2.status = 'active'），就会把右表为 NULL 的行过滤掉，等效于变相转成 INNER JOIN。
- 正确做法：把右表的筛选条件移到
ON子句里，例如LEFT JOIN orders t2 ON t1.id = t2.user_id AND t2.status = 'active' - 错误写法：
LEFT JOIN orders t2 ON t1.id = t2.user_id WHERE t2.status = 'active'—— 这会剔除所有没订单或订单非 active 的用户 - 如果必须在
WHERE里判断右表，得显式允许NULL：WHERE t2.status = 'active' OR t2.status IS NULL，但语义已不同，慎用
多表LEFT JOIN顺序影响结果吗
影响很大。SQL 中 LEFT JOIN 是左结合的，t1 LEFT JOIN t2 LEFT JOIN t3 等价于 (t1 LEFT JOIN t2) LEFT JOIN t3，中间结果集决定后续可匹配范围。
- 若想确保 t1 全量保留，t3 必须基于 t1+t2 的联合结果来关联，不能跳过 t2 直接“从 t1 拉 t3”
- 常见陷阱：写成
t1 LEFT JOIN t2 ON ... LEFT JOIN t3 ON t1.id = t3.user_id—— 这里t3只跟t1关联，和t2无关，但若t2有筛选逻辑，实际业务意图可能被破坏 - 性能上，越早过滤（如用
WHERE限定 t1 主键范围）越能减少中间结果集大小
用LEFT JOIN做“存在性判断”比子查询快吗
多数情况下更快，尤其当右表有合适索引、且只需判断“有无”时。MySQL 和 PostgreSQL 都能对 LEFT JOIN ... WHERE right_col IS NULL 做较优执行计划，而相关子查询（如 NOT EXISTS）在某些版本中可能重复执行。
- 推荐写法：
SELECT t1.* FROM users t1 LEFT JOIN orders t2 ON t1.id = t2.user_id WHERE t2.user_id IS NULL - 避免写成：
SELECT * FROM users t1 WHERE NOT EXISTS (SELECT 1 FROM orders t2 WHERE t2.user_id = t1.id)—— 不是语法错，但在大表 + 低选择率场景下执行计划易劣化 - 注意：如果右表关联字段没有索引，
LEFT JOIN会变成嵌套循环，比带索引的子查询还慢
LEFT JOIN后COUNT(*)和COUNT(右表字段)区别在哪
COUNT(*) 统计的是连接后的行数（含右表为 NULL 的行），COUNT(t2.id) 只统计右表非 NULL 的匹配行数——这是合并数据时最常混淆的点。
- 要统计“每个用户有多少订单”，必须用
COUNT(t2.order_id)，不是COUNT(*) - 若误用
COUNT(*)，用户没订单时也会算作 1 行，导致总数虚高 - 聚合前记得
GROUP BY t1.id，否则 MySQL 5.7+ 会报错（严格模式下不允许非分组字段出现在 SELECT 中）
真正难的不是写对 JOIN，而是每次加一个新表、换一个过滤条件时，都得重想一遍数据流从哪来、到哪去、中间哪些行会被意外截断——稍不注意，LEFT JOIN 就变成了隐形的 INNER JOIN。
