在分析电商或交易系统的订单明细时，我们往往面对的是一张字段细碎、行数庞大的表。要想看清不同商品类目、不同城市或者不同支付渠道的订单分布情况，不能靠肉眼翻数据，而要用SQL的分组与聚合能力把明细压缩成可读的统计结果。下面先通过一张示意图建立直观印象。
GROUP BY是SQL里最基础也最常用的分组手段。它按照一个或多个列的取值，把具有相同值的行划分到同一个分组中，再对每个分组应用聚合函数。比如我们有一张order_detail表，字段包括order_id、user_id、city、category、amount、pay_type。如果想看每个城市的订单总数和销售总额，可以写：
SELECT
city,
COUNT(order_id) AS order_cnt,
SUM(amount) AS total_amount
FROM order_detail
GROUP BY city
ORDER BY total_amount DESC;
这段代码中，GROUP BY city让数据库先按城市拆分成若干子集，再在每个子集里算订单数和金额合计。需要注意，SELECT后面出现的非聚合列必须全部写在GROUP BY里，否则在标准SQL中会报错。另外，聚合函数会忽略NULL值，如果amount存在NULL，SUM结果可能偏小，提前用COALESCE处理更稳妥。
多列分组也很常见。比如同时按城市和品类统计，只需在GROUP BY后追加列名。这样能看出哪个城市更偏好哪类商品。但分组维度越多，行数膨胀越明显，要结合业务取舍。如下示例：
SELECT
city,
category,
COUNT(*) AS cnt,
AVG(amount) AS avg_amount
FROM order_detail
GROUP BY city, category;
除了基础聚合，很多时候我们要做“透视”动作，也就是把某个分类字段的不同取值变成列。原生SQL没有PIVOT的数据库可以用CASE WHEN配合聚合模拟。例如统计各支付类型的订单量分布：
SELECT
city,
COUNT(CASE WHEN pay_type = 'alipay' THEN 1 END) AS alipay_cnt,
COUNT(CASE WHEN pay_type = 'wechat' THEN 1 END) AS wechat_cnt,
COUNT(CASE WHEN pay_type = 'card' THEN 1 END) AS card_cnt
FROM order_detail
GROUP BY city;
这里COUNT里的CASE WHEN在条件不满足时返回NULL，从而不被计数，实现按列拆分的透视效果。这种写法兼容几乎所有关系型数据库，逻辑也清晰。如果数据库支持PIVOT语法，如SQL Server，也可以用专用关键字，但可移植性较差。
当我们想看分组内的占比而非绝对值时，窗口函数比子查询更优雅。用SUM() OVER()算出总体基准，再除一下即可。下面例子展示每个品类占全部销售额的比例：
SELECT
category,
SUM(amount) AS cat_amount,
SUM(amount) * 1.0 / SUM(SUM(amount)) OVER () AS ratio
FROM order_detail
GROUP BY category;
注意这里用了SUM(SUM(amount)) OVER ()，内层SUM是分组聚合，外层SUM OVER是不分组求和，属于嵌套聚合加窗口的典型写法。这样一行就能同时拿到分组值与全局占比，不用再 JOIN 汇总表。
实际分析订单分布时，还有几个容易踩的坑。一是过滤分组要用HAVING而不是WHERE，因为WHERE在聚合前生效，无法筛选聚合结果。二是日期分组常被忽略时区，建议先用CONVERT_TZ或统一转成日期字符串再GROUP BY。三是明细表很大时，GROUP BY前尽量用WHERE缩小范围，或者依赖索引覆盖，否则全表扫描会非常慢。
总结来说，GROUP BY加聚合函数解决了“按什么拆、算什么指标”的问题，CASE WHEN实现了轻量透视，窗口函数补足了分组内与全局的关系。掌握这几招，订单明细里的分布规律就能用几行SQL清晰呈现，为运营决策提供直接依据。