LEFT JOIN 后加 DISTINCT 本质是双重暴力扫描，先完成全量JOIN再全量去重，导致IO、CPU、内存开销翻倍；应优先将右表过滤移至ON条件或用子查询/聚合压缩右表规模。
LEFT JOIN 后加 DISTINCT 本质是双重暴力扫描
DISTINCT 不会减少 JOIN 过程中的数据膨胀，它只在 JOIN 完成后对最终结果集做一次全量去重。这意味着数据库必须：先完成所有 LEFT JOIN 的逻辑（包括右表全表扫描、行复制、NULL 补全），再把膨胀后的几万甚至百万行拉进内存或临时磁盘，最后用哈希或排序方式逐行比对所有 SELECT 字段组合。两步叠加，IO、CPU、内存开销翻倍。
常见现象：EXPLAIN 中同时出现 Using temporary 和 Using filesort；rows 显示几十万，但实际业务只需几百条有效记录；响应时间从 200ms 跳到 8s+。
- LEFT JOIN 已让
users表的 1000 行变成 3270 行（因每个用户平均有 3 条日志），DISTINCT 还得对这 3270 行的全部字段做比较 - 如果 SELECT 包含
TEXT或JSON字段，MySQL 会直接放弃内存哈希，强制走磁盘排序 -
DISTINCT会阻断谓词下推——外层WHERE u.status = 'active'无法提前过滤左表，优化器被迫先 JOIN 再筛
为什么 ON 里写条件比 WHERE 里写快十倍
LEFT JOIN 后跟 WHERE b.status = 'done' 看似简洁，实则让语义退化为 INNER JOIN：所有 b.status IS NULL 的左表行被干掉，优化器可能因此放弃使用 b 表上的索引，转而先全连再过滤。真正高效的做法，是把右表过滤提前到 JOIN 阶段。
- ❌ 错误写法：
LEFT JOIN t_log l ON u.id = l.user_id WHERE l.status = 'success'——WHERE会过滤掉无日志用户 - ✅ 正确写法：
LEFT JOIN (SELECT * FROM t_log WHERE status = 'success') l ON u.id = l.user_id - ✅ 更优写法：
LEFT JOIN t_log l ON u.id = l.user_id AND l.status = 'success'—— 条件塞进ON，保留左表语义，且能利用status上的索引
替代 DISTINCT 的三种低开销方案
核心思路始终是：不让右表多行直接参与 JOIN。用子查询、窗口函数或聚合压缩右表至单行，JOIN 前就控制输出规模，避免后期硬扛去重。
- 要最新一条完整记录 → 用
ROW_NUMBER()：LEFT JOIN (SELECT user_id, ip_addr, log_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY log_time DESC) AS rn FROM t_log) l ON u.id = l.user_id AND l.rn = 1
- 只要统计值（如登录次数）→ 用
GROUP BY子查询：LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM t_log GROUP BY user_id) l ON u.id = l.user_id
- 右表极小且稳定（如配置表）→ 改用
EXISTS替代 JOIN：SELECT u.* FROM users u WHERE EXISTS (SELECT 1 FROM t_log l WHERE l.user_id = u.id AND l.status = 'active')，不产生任何重复行
DISTINCT 在 JOIN 场景中几乎从不“修复”问题
加 DISTINCT 是最省事的写法，但它掩盖了两个关键事实：一是你没理清主从表的语义边界，二是你没定义清楚“一行代表什么”。比如查“用户+最近订单”，DISTINCT u.id, o.order_no 看似去重，实则无法保证 o.order_no 是最新的——只要存在两条不同订单号，它们就会同时保留。真正该问的是：这个字段要不要参与业务逻辑？要不要带时间戳？要不要聚合？而不是靠 DISTINCT 强行压平。
最容易被忽略的一点：DISTINCT 对 NULL 值去重有效，但对业务上“空值有意义”的场景（如未填写城市、未选择分类）反而造成信息丢失。这时候你真正需要的不是去重，而是明确的填充规则或状态标记。
