JOIN顺序和驱动表选择直接影响聚合结果正确性，必须以业务主实体表（如orders）为驱动表，INNER JOIN强依赖表，LEFT JOIN可选维度表，并确保GROUP BY包含所有非聚合字段。
JOIN顺序和驱动表选择直接影响聚合结果正确性
多表关联聚合出错，八成是因为没想清楚哪张表该当驱动表。比如 orders、order_items、products、categories 四张表连查时，如果从 categories 开始 LEFT JOIN，而它和 orders 没有直接外键关系，就会产生大量 NULL 或重复膨胀行——聚合值直接失真。
实操建议：
- 以业务主实体表为起点（通常是交易类或事实表），如
orders； - 用 INNER JOIN 连接强依赖表（如
order_items），确保每条记录都有对应明细； - 对可选维度表（如
categories）用 LEFT JOIN，并确认 ON 条件只基于已存在字段（例如products.category_id = categories.id，而非跨两层推导）； - 在 JOIN 后立即用
WHERE过滤驱动表条件（如orders.created_at >= '2024-01-01'），避免先膨胀再过滤。
GROUP BY 必须包含所有非聚合字段，且顺序无关但字段必须显式列出
三个以上表关联后，SELECT 中只要出现非 AVG()、SUM() 类字段，就必须进 GROUP BY。很多人图省事写 GROUP BY 1,2,3，但在多表 JOIN 下极易因字段顺序变动或别名覆盖导致分组逻辑错乱。
常见错误现象：
-
SELECT c.name, p.brand, SUM(oi.quantity) FROM ... GROUP BY c.name—— 缺少p.brand，MySQL 5.7+ 会报错，PostgreSQL 直接拒绝； - 用子查询或 CTE 先聚合再 JOIN，却忘了在外部 SELECT 中把维度字段也放进
GROUP BY； - JOIN 后某张表有同名列（如两张表都有
id），GROUP BY id语义模糊，必须写成GROUP BY orders.id。
用 CTE 拆解聚合步骤比单条超长 SQL 更可控
四张表硬写在一个 SELECT 里，调试时改一个条件就要重跑全部，还容易漏掉某张表的去重逻辑。CTE 不是炫技，是把“先算订单总金额”“再按品类归并”“最后补上运营标签”这些步骤显式分离。
示例结构（PostgreSQL / SQL Server）：
WITH order_summary AS ( SELECT o.id, o.user_id, SUM(oi.price * oi.quantity) AS total FROM orders o INNER JOIN order_items oi ON o.id = oi.order_id GROUP BY o.id, o.user_id ), category_enriched AS ( SELECT os.*, c.name AS category_name FROM order_summary os INNER JOIN products p ON os.product_id = p.id INNER JOIN categories c ON p.category_id = c.id ) SELECT category_name, COUNT(*) AS order_count, AVG(total) AS avg_order_value FROM category_enriched GROUP BY category_name;
注意点：
- 每个 CTE 只做一件事，不混入 WHERE 过滤（除非是为减少中间数据量）；
- CTE 中的 GROUP BY 字段，必须能被下游 CTE 唯一识别（避免用
SELECT *）； - MySQL 8.0+ 支持 CTE，但旧版本需改用临时表或嵌套子查询。
LEFT JOIN + 聚合函数内部判空比 WHERE 过滤更安全
当需要保留主表全部记录（比如统计每个用户的历史订单数、即使没下单也要显示 0），很多人习惯写 WHERE c.status = 'active'，结果把没关联到 categories 的订单全过滤掉了。
正确做法是把条件下沉到 JOIN 的 ON 子句或聚合函数内：
- 用
LEFT JOIN categories c ON p.category_id = c.id AND c.is_deleted = false，而不是WHERE c.is_deleted = false； - 统计时用
COUNT(c.id)而非COUNT(*)，避免把 NULL 行也算进去； - 求平均值前加
AVG(CASE WHEN c.id IS NOT NULL THEN p.price END)，明确排除无效维度关联。
复杂点在于：不同数据库对 NULL 的聚合行为略有差异（如 SQLite 的 AVG() 会跳过 NULL，而某些 OLAP 引擎可能报错），上线前务必用真实 NULL 数据验证。
