分组查询结果暴增主因是前置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时，确认中间表是否被“跳过”——比如
，但漏了
和
之间的
，A和C就可能间接形成笛卡尔积
LEFT JOIN中WHERE和ON放错位置，为什么也会撑大结果集？
这不是严格意义的笛卡尔积，但效果类似：本该被过滤掉的右表行，因为错误地塞进
，导致LEFT JOIN把它们全保留为空值，反而让中间结果集变胖。
：只关联已发货的记录，JOIN结果集干净
：先全量LEFT JOIN（包括
的行），再过滤——那些NULL行虽被WHERE干掉，但已在JOIN阶段参与了组合计算，内存和IO都白花了
更隐蔽的坑：
✅；而
❌（后者会把无客户匹配的订单也踢掉，变成INNER JOIN语义）
如何快速验证是不是JOIN失控导致的分组失真？
别一上来就重写整个查询，先用几条轻量命令定位问题源头。
把
临时换成
跑一遍，如果行数依然爆炸，说明连接条件本身就有问题，不是NULL行导致的
在SELECT里加个计数：
，看单个订单是否对应几百个order_items——如果是，说明
没按订单聚合就直接JOIN了
对右表字段加
再聚合（如
）能缓解，但只是掩盖问题；真正该做的是在JOIN前用子查询收拢右表（例如
）
最容易被忽略的一点：类型不一致也会让索引失效，进而让JOIN退化为全表扫描配对。比如
是
，而
是
，即使值相同，数据库也无法走索引，只能硬扫——这种“隐性笛卡尔积”查起来特别慢，还看不出明显错误提示。
JOINONON orders.id = order_items.order_idON 1=1ON trueON a.id = a.idA JOIN B JOIN CBCONONON b.status = 'shipped'WHERE b.status = 'shipped'b.status IS NULLLEFT JOIN customers c ON o.customer_id = c.id AND c.deleted_at IS NULLLEFT JOIN customers c ON o.customer_id = c.id WHERE c.deleted_at IS NULLLEFT JOININNER JOINCOUNT(*) OVER (PARTITION BY orders.id)order_itemsDISTINCTCOUNT(DISTINCT order_items.id)(SELECT order_id, SUM(quantity) FROM order_items GROUP BY order_id)orders.customer_idBIGINTcustomers.idVARCHAR