多表关联后直接GROUP BY会导致统计失真，因JOIN先“炸开”行再分组，使COUNT(*)虚高、SUM()重复累加；正确做法是先对明细表预聚合再LEFT JOIN主表。
多表关联后直接 GROUP BY 很容易统计失真，根本原因是 JOIN 先展开行、再分组——同一主表记录若匹配多条明细，就会被重复计入聚合，导致 COUNT(*) 虚高、SUM() 重复累加。
为什么 JOIN 后 GROUP BY 会把 SUM 和 COUNT 算错
数据库执行顺序固定为 FROM → JOIN → WHERE → GROUP BY。一旦发生一对多关联（比如一个订单对应多个订单项），JOIN 阶段就把 1 行订单“炸开”成 N 行，GROUP BY order_id 看到的已是膨胀后的中间结果集。
-
COUNT(*)统计的是这 N 行，不是原始订单数 -
SUM(item_price)把每个订单项价格加了一遍，但业务上通常只要订单维度的总金额，不该因项数不同而放大 - 即使你只
SELECT order_id, COUNT(*)，只要JOIN引入了多行，结果就不可信
正确做法：先对明细表预聚合，再 JOIN 宽表
把聚合逻辑从 GROUP BY 阶段前移，让数据库在 JOIN 前就完成明细层汇总，避免行数爆炸。
- 用子查询或 CTE 对明细表按关联键（如
order_id）提前GROUP BY，生成单行汇总结果 - 再用
LEFT JOIN关联主表，确保主表记录不丢失 - 示例：查订单数和总金额，别写
orders o LEFT JOIN order_items i ON o.id = i.order_id GROUP BY o.id；改写为：
SELECT o.id, o.created_at, co.item_count, co.total_amount FROM orders o LEFT JOIN ( SELECT order_id, COUNT(*) AS item_count, SUM(price) AS total_amount FROM order_items GROUP BY order_id ) co ON o.id = co.order_id
LEFT JOIN + GROUP BY 时，COUNT(*) 和 COUNT(字段) 行为完全不同
这是线上最常踩的语义坑：很多人想统计“每个用户的订单数”，却写了 COUNT(*)，结果所有用户都返回 1（因为 LEFT JOIN 保证左表一行必存在）。
-
COUNT(*)统计的是分组后的行数，哪怕右表全为NULL，这一行也计入 -
COUNT(o.id)只统计o.id非NULL的行——这才是真正匹配到的订单数 - 安全写法：用右表主键或明确非空字段，如
COUNT(orders.id)，别用COUNT(orders.status)（status 可能为 NULL） - 如果要显示“0 订单用户”，必须配合
COALESCE(COUNT(orders.id), 0)，否则COUNT本身不会返回NULL
JOIN 顺序影响分组粒度，但不能靠调整语法顺序修复
有人试图通过换 FROM 表位置来“控制分组”，比如把小表放前面，但这只是误导——GROUP BY 的粒度由最终 JOIN 展开后的行结构决定，跟书写顺序无关。
-
A LEFT JOIN B LEFT JOIN C的分组基础是 (A ⨝ B) ⨝ C 的联合行，不是 A 的原始主键 - 真正可控的是：是否让 B 和 C 各自先聚合，再与 A 关联；或者确认 B、C 在关联字段上是否有唯一约束（如
UNIQUE(order_id)） - 检查手段：对右表执行
SELECT count(*) FROM table GROUP BY join_key HAVING count(*) > 1，看是否存在一对多 - 若存在，且无法加约束，就必须走子查询预聚合，没有捷径
最易被忽略的一点：当明细表数据量极大时，子查询预聚合不仅修正语义，还能显著提升性能——它把千万级 order_items 压缩成万级汇总结果再 JOIN，比先 JOIN 再 GROUP BY 少读、少连、少排序。
