LEFT JOIN后COUNT(*)虚高是因为一对多关联导致行数膨胀，如1单×3明细×2日志=6行，统计的是物理行而非业务实体；唯一可靠解法是先对各右表按关联键预聚合再JOIN。
LEFT JOIN后COUNT(*)为什么总是虚高
这不是函数错了，是数据被重复拉平了。比如一个订单在order_items表里有 3 条明细，在order_logs表里有 2 条操作记录，LEFT JOIN之后这单就变成 3 × 2 = 6 行——COUNT(*)统计的是这 6 行，不是 1 单。
COUNT(*)数的是连接后的总行数，和业务含义完全脱钩。COUNT(orders.id)在LEFT JOIN中也无效，因为orders.id不为空，照样会把空匹配行算进去。
- 唯一可靠的是先对每个右表独立
GROUP BY汇总，再用主键或维度字段关联 - 多表
LEFT JOIN必须用子查询预聚合，不能裸连明细表 - 子查询别名要明确，例如
(SELECT pr_code, COUNT(*) AS item_cnt FROM order_items GROUP BY pr_code) items
LEFT JOIN的WHERE条件为什么不能写在WHERE里
放在WHERE里看似一样，实际执行顺序完全不同：先全量配对再过滤，中间结果已膨胀。错误写法：LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'，效果等同于INNER JOIN——所有c.status为NULL的左表行都被过滤掉了，且白跑一遍空匹配。
- 正确写法是把右表过滤条件移入
ON子句：LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active' - 如果业务需要保留所有订单，又只取 VIP 用户信息，
WHERE里绝不能碰c.level这类右表字段 - ORM 生成 SQL 时容易漏掉这个细节，建议人工检查每个
LEFT JOIN后的ON是否包含全部业务约束
多个LEFT JOIN串在一起为什么会指数级膨胀
两个LEFT JOIN串在一起，如果右表各自一对多，结果就是乘法级膨胀——比如 A 表 1 行 × B 表 3 行 × C 表 2 行 = 6 行，而不是你预期的 1+3+2=6 行。典型错误：SELECT a.pr_code, COUNT(b.id), COUNT(c.id) FROM a LEFT JOIN b ON a.pr_code = b.pr_code LEFT JOIN c ON a.pr_code = c.pr_code GROUP BY a.pr_code，此时COUNT(c.id)会变成 3（B 的行数），不是 C 的真实计数。
- 必须把 B、C 分别写成带
GROUP BY的子查询，只返回关联键 + 聚合值（如COUNT(*)、SUM(amount)） - 主查询用
LEFT JOIN连这些子查询，ON条件只比对键字段，不再引入新行 - 子查询里漏
GROUP BY关联字段，等于没写，又变交叉连接
怎么快速验证SQL有没有笛卡尔积膨胀
别等查完才看性能，要在写完 SQL 第一轮就跑EXPLAIN。重点盯三处：type列出现ALL或index说明走了全表/全索引扫描；key为空表示没走索引；rows预估数突增数十倍，大概率断链或漏条件。
- 加窗口函数快速验证：
SELECT u.id, COUNT(*) OVER (PARTITION BY u.id) AS order_cnt FROM users u LEFT JOIN orders o ON u.id = o.user_id ORDER BY order_cnt DESC LIMIT 5，一眼揪出异常高的u.id - 对每个
JOIN后的中间结果加LIMIT 5查看行数是否合理；若某步后行数突增，大概率断链了 - 线上不敢跑全量？加
LIMIT 100不是为了“先看看”，而是为了秒级确认问题规模：如果LIMIT 100都卡住或返回重复主键，说明中间结果早已失控
真正难的不是写出聚合子查询，而是判断哪张表该聚合、按什么字段聚合、是否要加时间范围或状态过滤——这些都得贴着业务逻辑抠。一不留神，子查询里漏了个AND deleted = 0，结果还是错的。
