分组查询结果暴增主因是前置JOIN失控导致笛卡尔积式膨胀，而非GROUP BY本身错误；应检查JOIN条件是否完备、类型是否一致、ON与WHERE位置是否正确，并优先在聚合前用子查询收拢右表数据。

分组查询结果暴增，不是GROUP BY写错了，而是前面的JOIN已经失控了。 你看到COUNT(*)翻倍、SUM()异常放大、执行超时，大概率是JOIN没约束住关联基数，提前产生了笛卡尔积式膨胀——这时候再怎么调GROUP BY都没用。

为什么EXPLAIN里看到Nested Loop + actual rows远大于左表行数？

这是PostgreSQL中笛卡尔积最直接的信号。MySQL里对应的是type: ALL或Extra里出现Using join buffer。本质是数据库在做JOIN时，没找到有效的连接条件，退化成了全量配对。

• 检查每个JOIN后是否紧跟着ON子句，且该子句至少含一个左表列和一个右表列（比如ON orders.id = order_items.order_id）
• 警惕ON 1=1、ON true、或ON a.id = a.id这类恒真/自等式，它们等于没写条件
• 多表JOIN时，确认中间表是否被“跳过”——比如A JOIN B JOIN C，但漏了B和C之间的ON，A和C就可能间接形成笛卡尔积

LEFT JOIN中WHERE和ON放错位置，为什么也会撑大结果集？

这不是严格意义的笛卡尔积，但效果类似：本该被过滤掉的右表行，因为错误地塞进ON，导致LEFT JOIN把它们全保留为空值，反而让中间结果集变胖。

• ON b.status = 'shipped'：只关联已发货的记录，JOIN结果集干净
• WHERE b.status = 'shipped'：先全量LEFT JOIN（包括b.status IS NULL的行），再过滤——那些NULL行虽被WHERE干掉，但已在JOIN阶段参与了组合计算，内存和IO都白花了
• 更隐蔽的坑：LEFT JOIN customers c ON o.customer_id = c.id AND c.deleted_at IS NULL ✅；而LEFT JOIN customers c ON o.customer_id = c.id WHERE c.deleted_at IS NULL ❌（后者会把无客户匹配的订单也踢掉，变成INNER JOIN语义）

如何快速验证是不是JOIN失控导致的分组失真？

别一上来就重写整个查询，先用几条轻量命令定位问题源头。

• 把LEFT JOIN临时换成INNER JOIN跑一遍，如果行数依然爆炸，说明连接条件本身就有问题，不是NULL行导致的
• 在SELECT里加个计数：COUNT(*) OVER (PARTITION BY orders.id)，看单个订单是否对应几百个order_items——如果是，说明order_items没按订单聚合就直接JOIN了
• 对右表字段加DISTINCT再聚合（如COUNT(DISTINCT order_items.id)）能缓解，但只是掩盖问题；真正该做的是在JOIN前用子查询收拢右表（例如(SELECT order_id, SUM(quantity) FROM order_items GROUP BY order_id)）

最容易被忽略的一点：类型不一致也会让索引失效，进而让JOIN退化为全表扫描配对。比如orders.customer_id是BIGINT，而customers.id是VARCHAR，即使值相同，数据库也无法走索引，只能硬扫——这种“隐性笛卡尔积”查起来特别慢，还看不出明显错误提示。