多表join时group by必须用带别名的主表字段，否则报错或结果错误；count(*)在left join中恒为1，应改用count(右表非空字段)；一对多关联需预聚合明细表再join，避免sum/count虚高。
GROUP BY 必须用主表字段，且带前缀
直接写 GROUP BY id 会出错——数据库不知道你要按哪张表的 id 分组。多表 JOIN 时，只要表里有同名列（比如 id、name），就必须加表别名前缀。
常见错误现象：查询返回“Expression not in GROUP BY clause”或结果随机、漏数据。
- 正确写法：
GROUP BY u.id, u.name（假设u是用户表别名） - 错误写法：
GROUP BY id或GROUP BY user.id（别名没定义或写错） - 如果 SELECT 里用了别名如
u.name AS username，GROUP BY 仍得写u.name，不能写username - 主表字段必须出现在 SELECT 列表中（除非被聚合函数包裹），否则 MySQL 8.0+ 和 PostgreSQL 会直接拒绝执行
LEFT JOIN 后 COUNT(*) 为什么总显示 1？
这不是 bug，是语义误解：COUNT(*) 统计的是结果集的行数，而 LEFT JOIN 保证左表每行至少出现一次——哪怕右表没匹配，这行也存在，COUNT(*) 就是 1。
要统计“每个用户实际下了几单”，得用右表的非空字段：
- 用
COUNT(orders.id)，前提是orders.id是主键或定义为 NOT NULL - 配合
COALESCE(COUNT(orders.id), 0)让无订单用户显示为 0 - 别用
COUNT(*)或COUNT(1)替代——它们在 LEFT JOIN 下行为一致，但语义模糊，掩盖真实逻辑 - 如果右表字段允许 NULL（比如
orders.status），COUNT(orders.status)会漏掉 status 为 NULL 的有效订单，不可靠
一对多关联导致 SUM/COUNT 虚高怎么办？
JOIN 阶段就把 1 行“炸开”成 N 行（比如 1 个订单 → 3 条商品明细），GROUP BY 再聚合时已无法还原原始粒度，SUM 和 COUNT 必然翻倍。
正确做法是预聚合：先对明细表按外键汇总，再 JOIN 主表。
- 错误写法：
FROM orders o LEFT JOIN order_items i ON o.id = i.order_id GROUP BY o.id - 正确写法：子查询先聚合
order_items，再 JOIN：SELECT o.id, COALESCE(i.item_count, 0) AS item_count FROM orders o LEFT JOIN ( SELECT order_id, COUNT(*) AS item_count FROM order_items GROUP BY order_id ) i ON o.id = i.order_id
- 若需多个指标（如商品数、总金额），都在子查询里一并算出：
COUNT(*), SUM(price)，避免主查询重复炸开 - 预聚合后 JOIN 的数据量大幅下降，性能通常提升一个数量级
多表 JOIN + GROUP BY 性能突然变慢？
不是 SQL 写错了，很可能是优化器没走索引分组，或者驱动表选错。
关键检查点：
-
GROUP BY字段必须全部来自主表（如users.id），避免跨表字段（如orders.status）——否则 MySQL 可能放弃索引分组 - 在 JOIN 条件字段上建联合索引，顺序按 JOIN 顺序排，例如
orders(user_id, created_at)配合ON u.id = o.user_id - 用
EXPLAIN看type是否为ALL或index；key_len是否充分利用索引长度 - 三张以上表 JOIN 时，优先让数据量最小的表做驱动表（尤其是 LEFT JOIN 左侧），避免大表被反复扫描
