left join后行数增多是因右表一对多导致左表行被复制，需先用count(*)对比验证，再查右表连接键重复性，过滤条件应置于on而非where，并通过子查询预聚合控制右表粒度。
LEFT JOIN 后行数比左表原始行数多，不是 SQL 出错了，是它正在严格执行连接逻辑：只要右表对同一个连接键（比如 user_id）有 N 条记录，左表那行就会被复制 N 次。
怎么快速确认是不是一对多导致的膨胀
别急着改 SQL，先验证根源。执行这两条语句就能定位问题：
-
SELECT COUNT(*) FROM left_table记下左表原始行数 -
SELECT COUNT(*) FROM left_table LEFT JOIN right_table ON ...看 JOIN 后总行数是否明显更大 - 再跑
SELECT join_column, COUNT(*) FROM right_table GROUP BY join_column HAVING COUNT(*) > 1，有结果就坐实了一对多 - 对比
COUNT(*)和COUNT(DISTINCT left_table.id)，前者远大于后者，说明中间已发生复制
为什么把过滤条件写在 WHERE 里会让问题更隐蔽
写成 LEFT JOIN t_log l ON u.id = l.user_id WHERE l.status = 'active'，表面看是想筛日志，实际效果是：先完成全量匹配（可能已膨胀几十倍），再把所有 l.status IS NULL 或不等于 'active' 的行全部踢掉——LEFT JOIN 彻底退化为 INNER JOIN。
正确做法是把条件塞进 ON：
LEFT JOIN t_log l ON u.id = l.user_id AND l.status = 'active'
这样右表只拉符合条件的行进来，左表完整保留，从源头控量。
用子查询预聚合是最稳妥的解法
核心思路：不让右表以“多行”姿态参与 JOIN，而是先按业务主键压成单行，再连。例如统计每个用户的最新登录 IP：
SELECT u.id, u.name, p.max_ip<br>FROM users u<br>LEFT JOIN (<br> SELECT user_id, MAX(ip_addr) AS max_ip<br> FROM t_log<br> WHERE log_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)<br> GROUP BY user_id<br>) p ON u.id = p.user_id
关键细节：
-
GROUP BY字段必须和ON中右表字段严格一致，不能写成ON u.id = p.id - 业务过滤（如时间范围、状态）必须写在子查询内，不能挪到外层
WHERE - LEFT JOIN 未匹配时，
p.max_ip是NULL，如需默认值，用COALESCE(p.max_ip, 'N/A')
最容易被忽略的一点：JOIN 后的结果集，已经不是原始左表的行集合了。哪怕你只 SELECT 左表字段，中间过程也早已完成行级复制——这个物理膨胀发生在任何 GROUP BY 或 DISTINCT 之前。
