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 值去重有效，但对业务上“空值有意义”的场景（如未填写城市、未选择分类）反而造成信息丢失。这时候你真正需要的不是去重，而是明确的填充规则或状态标记。