left join后行数暴增是因右表对同一连接键存在多条记录，导致左表行被复制；应通过预聚合、row_number()或exists等方法控制右表粒度，避免逻辑膨胀。
为什么LEFT JOIN后行数暴增？
这不是SQL写错了，是JOIN在严格执行关系代数——只要右表对同一个连接键（比如user_id）有多条记录，左表那行就会被复制多次。比如users表100行，t_log里某个user_id出现7次，结果里就占7行。
常见错误现象：COUNT(*)查出的行数远超左表原始行数；加了DISTINCT但一选子表字段（如log_time）重复立刻回来；后续再JOIN第三张表，膨胀级联放大。
- 用
SELECT u.id, COUNT(*) OVER (PARTITION BY u.id)看每条用户被展开几次，>1 就说明右表存在一对多 -
WHERE l.status = 'active'写在LEFT JOIN后会把逻辑变成INNER JOIN，应挪到ON子句：LEFT JOIN t_log l ON u.id = l.user_id AND l.status = 'active' -
DISTINCT是对整行去重，不是按u.id单列去重；它不解决逻辑膨胀，只是事后擦除，还可能掩盖问题、触发隐式排序拖慢大表查询
用预聚合控制右表粒度
真正该做的，是在JOIN前让右表只输出你需要的那一行，而不是在结果上“打补丁”。适用于要汇总值（如登录次数、最新IP）的场景。
实操建议：
- 写子查询+
GROUP BY提前聚合：SELECT u.id, u.name, p.cnt, p.max_ip FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS cnt, MAX(ip_addr) AS max_ip FROM t_log GROUP BY user_id) p ON p.user_id = u.id - 确保子查询里的
GROUP BY字段和ON条件完全匹配，否则关联失效 - 避免在子查询里漏掉
WHERE过滤——比如想只统计近30天日志，必须在子查询内加WHERE log_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)，不能放到外层
用ROW_NUMBER()取单条明细
当你需要完整的一条子表记录（如最新一条订单、最近一次登录），ROW_NUMBER()比DISTINCT或GROUP BY更精准，且能保留所有字段。
实操建议：
- 窗口函数必须配合
ON条件中的rn = 1使用：LEFT JOIN (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM t_log) l ON u.id = l.user_id AND l.rn = 1 -
rn = 1绝不能写在WHERE里，否则LEFT JOIN会退化成INNER JOIN，没日志的用户直接消失 -
ORDER BY字段要有索引，否则ROW_NUMBER()开销巨大；若排序字段允许NULL，需明确NULLS LAST或NULLS FIRST（MySQL 8.0.22+支持）
用EXISTS替代JOIN判断存在性
如果只需要知道“有没有关联记录”，比如查“有订单的用户”或“没头像的用户”，EXISTS比LEFT JOIN ... IS NULL更清晰、无膨胀、性能通常更好。
实操建议：
- 写法简洁：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM t_log l WHERE l.user_id = u.id) - 避免
LEFT JOIN ... WHERE l.id IS NULL时误伤：如果t_log里user_id没唯一约束，一个用户多条日志会导致IS NULL判断失真；EXISTS天然无视数量，只关心是否存在 -
EXISTS子查询中SELECT 1比SELECT *更轻量，MySQL优化器也更容易走索引
最容易被忽略的一点：JOIN后的结果集，已经不是原始左表的行集合了。哪怕你SELECT只写左表字段，数据库仍按连接后的中间结果计算——行数、聚合逻辑、排序稳定性全变了。
