SQL同时分组聚合多个指标的实现方法

一个 GROUP BY 搞定所有指标？没错，SQL 就是这么设计的。你不需要写一堆子查询、CTE，更不用反复扫描同一张表，直接在同一个 GROUP BY 查询里塞进多个聚合函数，就能一次性完成多指标计算——这是标准 SQL 的原生能力。

为什么一个 GROUP BY 就能算多个指标

数据库优化器比你想象中聪明得多，它会把 COUNT(*)、SUM(amount)、A VG(price)、MAX(created_at) 这些聚合表达式统统塞进同一轮分组过程（比如哈希分组或排序分组）。物理上只读一次表、只做一次分组键匹配，所有指标共享中间结果。

但现实中，很多人偏偏要绕远路。最常见的是写多个 SELECT ... FROM orders GROUP BY region 子查询，再傻乎乎地 JOIN 起来——结果表被反复扫描，性能直线下降。更惨的是，在 MySQL 5.7 中，如果对同一派生表引用两次，直接报错 ERROR 1248: Every derived table must ha ve its own alias，折腾半天搞不定。

• 所有非聚合字段（比如 region）必须显式写在 GROUP BY 列表里，否则 PostgreSQL 或 MySQL 8.0+ 会直接报 ERROR 1140
• 聚合函数之间互不干扰，可以自由混用，但绝不能嵌套（比如 COUNT(SUM()) 这种写法是非法的）
• 大表或高并发场景下，反复扫描带来的 I/O 开销、加锁成本和执行计划解析开销，远高于单次内存分组带来的消耗

COUNT 条件统计必须用 CASE WHEN，别信 MySQL 的布尔返回值

这是一个常见的坑：MySQL 允许你写 COUNT(status = 'success')，但这玩意儿返回的其实是行数，而不是你想要的“成功订单数”。原因在于 status = 'success' 是布尔表达式，在 COUNT 中被转成了 1 或 0，而 COUNT() 统计的是非 NULL 值——所以结果就错了。这种写法不仅语义不清，而且跨数据库根本不可移植。

• 正确写法统一用：COUNT(CASE WHEN status = 'success' THEN 1 END)
• SUM(CASE WHEN ... THEN 1 ELSE 0 END) 虽然结果等价，但优化器更难识别它其实是计数操作，可能影响优化
• PostgreSQL 有个更清晰的写法 COUNT(*) FILTER (WHERE status = 'success')，但 MySQL、SQL Server、Oracle 都不支持，最后还是得老老实实回退到 CASE WHEN

不同时间窗口或业务条件的指标，仍要单扫

场景升级了：你想同时统计“近7天订单数”和“近30天复购用户数”。如果靠外层加 WHERE 分两次查，那又绕回了两次全表扫描的老路。必须把过滤逻辑下沉到聚合内部。

• MySQL 写法：COUNT(CASE WHEN created_at >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) THEN 1 END) AS week_orders
• PostgreSQL 写法：COUNT(*) FILTER (WHERE created_at >= current_date - 7) AS week_orders
• 避免写成 SUM(IF(..., 1, 0))：函数语义是求和，不是计数，部分优化器无法做聚合识别优化

容易被忽略的关键点

很多人以为只要加上 GROUP BY 就万事大吉了，但真正卡住查询性能或导致报错的，往往是隐式依赖和空值处理。

• A VG()、SUM()、MAX() 会自动忽略 NULL，但 COUNT(col) 也会忽略 NULL，而 COUNT(*) 不忽略——混用时逻辑容易错位，结果可能与你预期完全相反
• 当某组内所有 amount 都是 NULL 时，SUM(amount) 返回的是 NULL，不是 0。如果你需要返回 0，必须用 COALESCE(SUM(amount), 0) 处理
• 多列 GROUP BY a, b 时，如果 a 或 b 中有 NULL，它们会被当作独立分组值参与聚合，而不是“合并到一起”