分组查询本身不会直接产生笛卡尔积，但GROUP BY前的JOIN若遗漏或错写关联条件，会导致中间结果先膨胀为笛卡尔积，再被聚合，从而引发行数爆炸、SUM/COUNT失真、内存溢出或超时失败。
分组查询本身不会直接产生笛卡尔积，但当你在 GROUP BY 前或过程中混用多表连接且遗漏/错写关联条件时，中间结果集会先膨胀成笛卡尔积，再分组——这时你看到的不是“分组出错”，而是“行数爆炸”“聚合值翻倍”“内存溢出”或“超时失败”。
为什么 GROUP BY 会放大笛卡尔积危害
数据库执行顺序是：FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT。如果 JOIN 阶段已因缺失 ON 条件生成笛卡尔积，GROUP BY 不会“修复”它，只会对错误的海量中间行做聚合，导致：
- sum()、count() 等聚合结果远大于真实值（比如一个用户有 3 笔订单，却算出 12 笔）
-
GROUP BY字段若来自低基数表（如地区表只有 5 行），但被高基数表（如日志表百万行）无条件交叉，分组键实际变成“伪唯一” - MySQL 8.0+ 或 PostgreSQL 可能因临时磁盘空间不足直接报
ERROR 1114 (HY000): The table 'xxx' is full
检查 JOIN 条件是否完整且最小粒度匹配
多表 GROUP BY 查询中，每一对参与连接的表都必须有明确、有效、最小粒度的 ON 条件。常见疏漏点：
- 写了
INNER JOIN orders ON users.id = orders.user_id，但忘了给orders和products加条件，导致orders × products先爆炸 - 用非唯一字段连接，例如
ON users.city = locations.city（城市名重复），等价于隐式多对多 - 连接字段类型不一致，如
INT对VARCHAR，触发隐式转换，索引失效，全表扫描加剧笛卡尔风险 - 子查询未加过滤就参与连接，例如
(SELECT user_id FROM logs WHERE dt = '2026-04-16') t1返回 10 万行，却和users表无条件CROSS JOIN
确认 GROUP BY 维度与连接逻辑是否自洽
GROUP BY 的字段必须能唯一标识聚合粒度；若维度设计与连接方式冲突，数据库可能静默补全或报错（取决于 SQL mode），但结果不可信：
- 想按
users.region统计订单总额，但users和orders是 1:N 关系，而orders又和products是 N:M 关系——若没加products.category到GROUP BY，MySQL 5.7 默认允许，但 PostgreSQL 会报错：column "products.category" must appear in the GROUP BY clause - 使用
ANY_VALUE()或关闭ONLY_FULL_GROUP_BY掩盖问题，本质是放弃语义一致性，后续加新字段极易崩 - 聚合字段来自连接后的宽表，但某张表在连接中因条件缺失被“广播”，导致每个主键对应数百个副本，
COUNT(DISTINCT user_id)仍正确，但SUM(order_amount)已失真
快速验证是否存在隐式笛卡尔积
别等上线后查监控，执行前加两步诊断：
- 把原查询的
SELECT替换为SELECT COUNT(*)，再加LIMIT 10看执行计划：若rows显示百万级预估，且Extra出现Using temporary; Using filesort，大概率已膨胀 - 逐层剥离：先只查
FROM t1 JOIN t2 ON ...，确认行数合理；再加t3，观察行数增幅是否符合业务预期（比如 1000 用户 × 5 地区 = 5000 行，而非 1000 × 10000 日志） - 用
EXPLAIN FORMAT=TREE（MySQL 8.0+）看连接顺序和物化节点，重点找dependent join或未命中的key
最常被忽略的是：你以为加了 ON 就安全，但字段选错、类型不匹配、子查询没过滤，都会让数据库在连接阶段“假装正常”地生成笛卡尔积——而 GROUP BY 只是把它打包送进你的报表里。
