LEFT JOIN后行数比左表多是正常现象，源于右表连接键存在一对多关系（如一个用户对应多笔订单），导致左表记录被重复展开；常见原因包括右表连接字段无唯一约束、NULL值匹配或ON条件缺失引发笛卡尔积。
为什么LEFT JOIN后行数比左表多
这根本不是bug，而是连接语义的自然结果。只要右表在连接键上存在“一对多”关系，左表某一行就会被复制多次——比如一个用户下了3个订单，users LEFT JOIN orders 就会让该用户行出现3次。
- 最常见诱因：
orders表用user_id连接，但user_id不是它的主键或唯一约束 - 容易被忽略的隐性多对一：
user_addresses表里一个user_id对应5条历史地址，却没加is_current = 1过滤 - 笛卡尔积陷阱：漏写
ON条件，或条件恒为真（如ON 1=1），直接触发全量交叉
如何快速验证连接键是否唯一
别猜，用聚合查实。重点看右表在连接字段上是否存在重复值：
SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id HAVING COUNT(*) > 1 ORDER BY cnt DESC LIMIT 5;
- 如果返回结果非空，说明
user_id在orders表中不唯一 → 膨胀必然发生 - 同理检查左表连接键是否真能代表“一行一个业务实体”：比如
SELECT COUNT(*) FROM users和SELECT COUNT(DISTINCT user_id) FROM users不等，说明左表本身就有脏数据 - 注意 NULL：
GROUP BY会把所有NULL归为一组，若连接键允许 NULL，可能意外匹配出大量行
连接键不唯一时的处理策略
不能靠 DISTINCT 硬去重——它掩盖问题，还可能删掉合法的多行差异（比如同一用户的两笔不同订单）。正确做法是明确业务意图，再选收敛方式：
- 要“每个用户只取一条最新订单”：用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)+ 子查询过滤rn = 1 - 要“每个用户统计订单总数”：先
GROUP BY user_id聚合，再和左表JOIN，避免中间结果膨胀 - 要保留全部明细但控制膨胀幅度：确认右表是否真需全量参与——比如
LEFT JOIN user_profiles是为了头像URL，但该表有10个字段，其实只需SELECT user_id, avatar_url投影
为什么EXPLAIN里rows远超预期
EXPLAIN 中的 rows 是优化器预估的扫描行数，不是最终结果行数。当它远大于左表行数，往往意味着优化器误判了连接顺序或没走索引：
- 检查
key列：若为NULL，说明连接字段没走索引；右表连接键必须建索引，左表驱动字段也建议建 - 警惕
Using temporary; Using filesort：这表示中间结果太大，数据库被迫写磁盘临时表，此时膨胀已实际发生 - 复合索引要注意顺序：若
ON a.x = b.x AND b.y = 'val'，索引应建在b(x, y)而非b(y, x)
