多维分析SQL实战：从GROUP BY到CUBE与窗口函数-代码聚汇网

多维分析SQL实战：从GROUP BY到CUBE与窗口函数

一只流氓飘呀飘·2026-08-30·阅读 24 GEO检测（免费）

多维分析SQLGROUP BYROLLUP

|难度：普通|阅读约 21 分钟

选型之前先问各位一个问题：如果你手头有一张几亿行的订单表，产品经理让你按“渠道 + 月份 + 商品类目”三个维度看GMV，同时还要看每个维度组合的小计和总计，你第一版SQL会怎么写？是用三个GROUP BY UNION ALL？还是去Excel里拉透视表？如果你的第一反应是这两个，那这篇手册值得你花十分钟读完。

在大数据分析师这个岗位上，SQL不只是取数工具，更是你和业务方对话的语言。多维分析SQL就是这门语言里最值钱的那一块：它让你能用一条语句讲清楚“不同维度下的指标变化”，而不是在多个临时表之间来回倒腾。这篇文章不堆语法、不抄文档，我按自己实际做报表、做数仓、带新人的经验，把多维分析SQL从底层逻辑到实战写法再到性能优化完整梳理一遍。适合刚转行做数据分析的同学，也适合写了一年SQL但总觉得差点意思的初级开发。

1. 多维分析SQL的本质：维度、度量与粒度

1.1 看待数据的三个视角：维度、度量、粒度

先聊一个被很多人跳过的基础问题：多维分析到底在分析什么。我用一张超市小票来举例。小票上写着“2025年6月1日，华东区上海门店，张三买了一瓶可乐，3.5元”。这里的信息可以拆成三类：

维度：看数据的角度。日期、地区、门店、商品、用户，这些是维度。它们通常是文本或离散值，用来做分组和筛选。
度量：要看的值。金额、数量、利润、时长，这些是度量。它们通常是数值，用来做求和、平均、计数。
粒度：一行数据代表什么。这张小票如果是“一笔订单一行”，粒度是订单级；如果拆成“一单里的一个商品一行”，粒度就是订单明细级。

多维分析SQL做的事情就一句话：沿着某些维度对度量做汇总。你告诉SQL“按地区、按月份看销售额”，SQL就把相同地区和月份的记录分到同一组，把销售额加总。这就是多维分析的核心逻辑，没有高深的东西。

但问题在于，实际业务里维度不止两三个，指标也不止一种。用户要看的是“每个渠道、每个月、每个品类、每个新老客状态的GMV”，这种需求一出来，考验的就是你对维度组合的掌控能力。

1.2 多维分析SQL与“普通查询”的分界线在哪

很多人觉得自己会SQL，理由是能写SELECT、JOIN、WHERE。但多维分析SQL和普通查询有个明显的分界线：普通查询是取数据，多维分析SQL是在数据之上构建汇总视图。

普通查询回答的是“某条记录的某个字段是什么”，多维分析SQL回答的是“某个维度集合下的某个度量是多少”。一个典型的例子：

sql复制-- 普通查询：取出这个用户最近10笔订单
SELECT order_id, order_amount, created_at
FROM orders
WHERE user_id = 12345
ORDER BY created_at DESC
LIMIT 10;

再看这条：

sql复制-- 多维分析：该用户最近30天的订单金额按天汇总
SELECT DATE(created_at) AS day,
       SUM(order_amount) AS total_amount,
       COUNT(*) AS order_cnt
FROM orders
WHERE user_id = 12345
  AND created_at >= DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY)
GROUP BY DATE(created_at);

一条是明细查询，一条是聚合分析。前者帮你看“发生了什么”，后者帮你看“变化的规律是什么”。多维分析SQL的核心能力是后者，其中GROUP BY是最基本的骨架，窗口函数是骨架上的关节，CUBE和ROLLUP则是帮你一次性搞定多套维度组合的利器。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 聚合语法演进：从GROUP BY到CUBE的“一次扫描”之路

2.1 基础GROUP BY：先会走再会跑

GROUP BY是整个多维分析SQL的地基。它做的事是：把满足WHERE条件的数据按某些字段分组，然后在组内执行聚合函数。

sql复制SELECT region,
       MONTH(created_at) AS month,
       SUM(amount) AS gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY region, MONTH(created_at);

这个例子里，维度是region和month，度量是amount，聚合函数是SUM。执行逻辑分两步：先按region和month把数据分成若干个桶，再在每个桶里加总amount。凡是出现在SELECT后面的非聚合列，必须出现在GROUP BY里，这条规则很多新手栽过跟头，实际上是SQL的标准语义：你SELECT了一个维度列，就必须告诉数据库“按这个维度分组”。

实际写的时候还要注意两点。第一，GROUP BY后面的列顺序不影响结果，只影响中间分组的效率，排序上可能略有差异，但不用过度纠结。第二，不要在GROUP BY里写一长串表达式，比如GROUP BY DATE_FORMAT(created_at, '%Y-%m')，这种写法虽然能跑，但会显著影响索引利用效率，后文优化章节我会详细说。

2.2 ROLLUP：从小计到总计的递进

业务里常见的需求是“按地区看销售额，还要按总地区看总计”。最笨的办法是写两个SQL再UNION，但这样代码冗余，而且要扫两遍表。

ROLLUP就是为了解决这个问题。它能在一次扫描里，把明细分组、逐级小计、总计全部算出来：

sql复制SELECT region,
       MONTH(created_at) AS month,
       SUM(amount) AS gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY region, MONTH(created_at) WITH ROLLUP;

结果集里会多出几个“汇总行”，这些行的region或month为NULL，表示该位置的维度被收拢了。如果维度是“地区 + 月份”，ROLLUP会生成三层结果：

地区 + 月份：最细粒度的分组
地区：每个地区跨月份的合计
总计：全部数据的总和

我见过不少人对这些NULL汇总行很困惑，这里有个经验：如果你用WITH ROLLUP，而且维度字段本身允许NULL，那一定要用GROUPING()函数区分“这是汇总行”还是“数据里本来就有NULL”。这个问题放到2.4节细说。

ROLLUP适合“层级递进”的汇总，比如组织架构的部门到组、时间维度的年到月、地理维度的省份到城市。它的缺点是只能形成一条固定的“上卷路径”，如果业务方同时要“地区×月份”和“地区×品类”的多套组合，ROLLUP就覆盖不全了。

2.3 CUBE与GROUPING SETS：一组SQL算完所有维度组合

先看一个更现实的场景：你要看“渠道 + 月份 + 品类”三个维度下的GMV，业务方说“每个维度单独看、两两组合看、三个一起看，我全都要”。写6个SQL再加UNION？数据量小能忍，数据量大了就是灾难。

CUBE能一次性生成所有维度组合的汇总：

sql复制SELECT channel,
       MONTH(created_at) AS month,
       category,
       SUM(amount) AS gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY channel, MONTH(created_at), category WITH CUBE;

CUBE会对所有维度做幂集的展开：三个维度能生成2^3=8种组合，从全维度明细到单项维度汇总到全表总计，全都包含。代价是结果集行数会膨胀，尤其维度多、基数大的时候，需要谨慎使用。

GROUPING SETS是更精细的控制。它让你显式声明“我要哪些维度组合”，不需要的就不算：

sql复制SELECT channel,
       MONTH(created_at) AS month,
       SUM(amount) AS gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY GROUPING SETS (
    (channel, MONTH(created_at)),
    (channel),
    (MONTH(created_at)),
    ()
);

这个写法直接指定了要四种组合：渠道+月份、渠道单独、月份单独、全表总计。相比CUBE少算了渠道×月份的某几类组合，结果集小，计算量也小，效率明显更高。

用的时候按照需求强度来选：分层的用ROLLUP，全组合用CUBE，只想要部分组合用GROUPING SETS。这是我在实践中摸出来的最简单判断逻辑。

2.4 GROUPING(): 区分“汇总行”和“数据里的NULL”

这个函数一定要单独讲，因为踩坑的人太多了。

ROLLUP或CUBE生成的汇总行里，被收拢的维度字段是NULL。但如果原始数据里这个维度字段本身就有NULL值，那结果集里的NULL就无法区分是汇总产生的，还是原始数据里带的。GROUPING()就是用来解决这个问题的：

sql复制SELECT region,
       GROUPING(region) AS is_region_total,
       MONTH(created_at) AS month,
       GROUPING(MONTH(created_at)) AS is_month_total,
       SUM(amount) AS gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY region, MONTH(created_at) WITH ROLLUP;

GROUPING(region)返回1，表示这一行是region维度的汇总行；返回0，表示region的值是实际明细值。这样你在前端渲染报表时，就可以自动把汇总行标记成“合计”，而不是误显示成“(null)”。

我记得有一次上线报表，测试环境数据里没有NULL值，一切正常；到了生产环境，有两条订单的地区字段为空，报表里突然多出两行“NULL - 3月 - 5000元”的假汇总，查了半天才发现是数据空值和ROLLUP汇总行混在一起。从那以后我写多维SQL的基本习惯就是：用了ROLLUP或CUBE，必带GROUPING()。

3. 窗口函数：多维分析的另一半拼图

3.1 同环比与LAG/LEAD：业务报表里最高频的需求

GROUP BY体系解决的是“分组汇总”，但业务方经常要的是“两组之间的差异”。最典型的就是“这个月GMV环比上个月涨了多少”。如果你只能用GROUP BY，就得把两个月的汇总结果再JOIN一次，非常别扭。窗口函数LAG和LEAD就是为此设计的。

sql复制SELECT MONTH(created_at) AS month,
       SUM(amount) AS gmv,
       LAG(SUM(amount), 1) OVER (ORDER BY MONTH(created_at)) AS prev_month_gmv,
       SUM(amount) - LAG(SUM(amount), 1) OVER (ORDER BY MONTH(created_at)) AS mom_diff,
       (SUM(amount) - LAG(SUM(amount), 1) OVER (ORDER BY MONTH(created_at))) 
         / LAG(SUM(amount), 1) OVER (ORDER BY MONTH(created_at)) AS mom_ratio
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY MONTH(created_at);

注意这里的关键点：窗口函数是在GROUP BY之后执行的。所以你可以先在GROUP BY里把月汇总算出来，然后用窗口函数在汇总结果基础上取上一行做比较。这个执行顺序非常重要，我见过很多新人写成“窗口函数里套窗口函数”或者“在WHERE里用窗口函数”，都会报错。

LAG表示取当前行往前第N行的值，LEAD表示取往后第N行的值。同环比报表里，LAG(字段, 1)是最常用的写法。如果你要算“同比”，一月对去年一月，LAG的偏移量就要根据月份跨度来动态处理，一般需要先用窗口函数生成带行号的维度表，再做自关联，SQL会稍微复杂，但思路还是同一个：先汇总、再比较。

3.2 用SUM OVER算累计值：库存、流水、活跃用户

累计值是多维分析里另一类高频需求。比如“截至每个月的累计GMV”“每天的新增用户数按周累计”。窗口函数的SUM配合OVER可以做到“分组内逐行累加”：

sql复制SELECT MONTH(created_at) AS month,
       SUM(amount) AS monthly_gmv,
       SUM(SUM(amount)) OVER (ORDER BY MONTH(created_at)) AS cumulative_gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY MONTH(created_at);

这里的SUM(SUM(amount))是两层聚合。内层SUM(amount)是GROUP BY算出来的月GMV，外层SUM(...) OVER (ORDER BY MONTH(created_at))是在月汇总结果上做累计加总。如果你漏了外层，直接写SUM(amount) OVER (...)也能跑，但累计的就是订单明细的累加值，不是你按月汇总之后的值，结果完全不对。

窗口函数里还可以指定PARTITION BY，实现“分组内的累计”：

sql复制SELECT region,
       MONTH(created_at) AS month,
       SUM(amount) AS monthly_gmv,
       SUM(SUM(amount)) OVER (PARTITION BY region ORDER BY MONTH(created_at)) AS region_cumulative_gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY region, MONTH(created_at);

这样每个地区有自己独立的累计曲线，区域之间互不干扰。加上PARTITION BY之后，窗口范围就从“全局”变成了“分区内”，理解这个差别是掌握窗口函数的关键。

3.3 排名三兄弟：ROW_NUMBER、RANK、DENSE_RANK怎么选

“每个品类销售额Top3的商品”“每个渠道转化率最高的5个页面”，这类需求用到的就是排名窗口函数。三个函数长得很像，语义差别很关键：

函数	相同值处理	示例结果	适用场景
ROW_NUMBER()	相同值按任意顺序分配唯一序号	1,2,3,4	去重、分页、取唯一一条
RANK()	相同值同号，后续跳号	1,1,3,4	竞赛排名、TopN但允许并列
DENSE_RANK()	相同值同号，后续不跳号	1,1,2,3	排名连续，比如“前3名”里并列也算

实际写TopN时，我通常用ROW_NUMBER去做“每个分组内取一条”，用RANK或DENSE_RANK去做“每个分组内取并列名次”。一个典型的“每个品类销售Top3商品”是这么写的：

sql复制SELECT category, product_name, sales_amount, rn
FROM (
    SELECT category,
           product_name,
           SUM(amount) AS sales_amount,
           RANK() OVER (PARTITION BY category ORDER BY SUM(amount) DESC) AS rn
    FROM orders
    WHERE created_at >= '2025-01-01'
      AND created_at < '2026-01-01'
    GROUP BY category, product_name
) t
WHERE rn <= 3;

注意这里窗口函数是在GROUP BY之后执行的，所以在窗口函数里可以直接用SUM(amount)，它对应的是分组后的聚合值。子查询包一层是为了在WHERE里过滤排名，因为窗口函数不能直接用在WHERE子句。这个“先聚合 → 再排名 → 再过滤”的三段式，是多维分析SQL里非常固定的套路，建议直接记下来当模板用。

4. 实战：电商业务里四个高频多维分析SQL

4.1 需求一：渠道×月份×品类的GMV汇总

假设订单表orders包含字段：order_id、user_id、channel、category、amount、created_at。业务方要看2025年每个月、每个渠道、每个品类的GMV，还要在这个结果基础上支持点击渠道或品类进行下钻。

直接用GROUP BY是最基础的答案：

sql复制SELECT channel,
       DATE_FORMAT(created_at, '%Y-%m') AS month,
       category,
       SUM(amount) AS gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY channel, DATE_FORMAT(created_at, '%Y-%m'), category
ORDER BY month, channel, category;

如果希望报表页面左侧的“小计”也能一次算出来，就换成GROUPING SETS，把渠道、月份、品类的单维度小计也一并算出来。实际渲染的时候，前端根据GROUPING()判断是不是汇总行。

4.2 需求二：每个品类销售额Top3商品

这个需求我在3.3节已经写了核心SQL。补充一个实际开发中容易遇到的问题：如果有两个商品销售额完全相同，ROW_NUMBER会随机（或按物理顺序）选一个当第一，可能导致“同一份数据两次查询结果不一致”。如果商品名相同、金额相同，业务上把它们视为并列，就必须用RANK或DENSE_RANK。

sql复制SELECT category, product_name, sales_amount, rank_no
FROM (
    SELECT category,
           product_name,
           SUM(amount) AS sales_amount,
           DENSE_RANK() OVER (PARTITION BY category ORDER BY SUM(amount) DESC) AS rank_no
    FROM orders
    WHERE created_at >= '2025-01-01'
      AND created_at < '2026-01-01'
    GROUP BY category, product_name
) t
WHERE rank_no <= 3;

如果还要在Top3结果里再算“Top3商品合计占品类总GMV的比例”，可以再套一层窗口函数，把品类总GMV也加进来。不过SQL会变得很长，实际项目中我更推荐分两步：先用视图或WITH子句把“品类商品汇总”算出来，再在下一层做占比计算，降低调试成本。

4.3 需求三：首单与复购行为分析

多维分析不光是订单维度，用户行为维度同样重要。比如“每月新客的首单GMV”“新客在首单后30天内的复购率”。这类分析通常要在用户维度上找到首单时间，再做归因。

sql复制WITH user_first_order AS (
    SELECT user_id,
           MIN(created_at) AS first_order_at
    FROM orders
    GROUP BY user_id
)
SELECT DATE_FORMAT(f.first_order_at, '%Y-%m') AS first_month,
       COUNT(DISTINCT f.user_id) AS new_user_cnt,
       COUNT(DISTINCT CASE WHEN o2.order_id IS NOT NULL THEN f.user_id END) AS repurchase_user_cnt,
       COUNT(DISTINCT CASE WHEN o2.order_id IS NOT NULL THEN f.user_id END) 
         / COUNT(DISTINCT f.user_id) AS repurchase_rate
FROM user_first_order f
LEFT JOIN orders o2
  ON f.user_id = o2.user_id
 AND o2.created_at > f.first_order_at
 AND o2.created_at <= DATE_ADD(f.first_order_at, INTERVAL 30 DAY)
GROUP BY DATE_FORMAT(f.first_order_at, '%Y-%m');

这个例子里的核心是靠WITH先算出每个用户的首单时间，再用LEFT JOIN把“首单后30天内的后续订单”关联回来。COUNT(DISTINCT CASE WHEN ...)是很实用的写法：用条件判断圈定符合复购定义的用户，再做去重计。

用COUNT(DISTINCT)的时候要注意，高基数用户场景下精确去重可能非常慢，尤其是几亿行的订单表。大规模数据仓库里更推荐用近似去重函数，比如Hive里的approx_count_distinct、ClickHouse里的uniqCombined，具体选型取决于你用的引擎。

4.4 需求四：活跃用户留存分析

留存分析是另一类典型的多维分析SQL。需要找一个目标时间窗口内的活跃用户，看这些用户在后续第N天、第N周是否还活跃。

简化的思路是：先选目标月份活跃用户集合，再和后续月份的活跃表做LEFT JOIN，统计匹配到的人数：

sql复制WITH target_users AS (
    SELECT DISTINCT user_id
    FROM user_active_log
    WHERE active_month = '2025-01'
),
follow_up AS (
    SELECT user_id,
           active_month
    FROM user_active_log
    WHERE active_month IN ('2025-02','2025-03','2025-04')
)
SELECT f.active_month,
       COUNT(DISTINCT t.user_id) AS retained_users,
       COUNT(DISTINCT t.user_id) / (SELECT COUNT(*) FROM target_users) AS retention_rate
FROM target_users t
LEFT JOIN follow_up f
  ON t.user_id = f.user_id
GROUP BY f.active_month;

这个SQL能跑，但实际生产环境里，用户活跃表动辄几十亿行，COUNT(DISTINCT)非常吃资源。通常的做法是提前把日活/月活用户集合做成中间表，或者用位图存储用户ID集合，再做交并集计算。这件事让我意识到，多维分析SQL写得好不好，不只看你能不能写出结果，还看你在数据量爆炸的时候能不能写出能跑完的结果。

5. 性能优化：多维SQL卡慢时先从哪下手

5.1 优化优先级：分区裁剪、谓词下推、维度过滤

写多维分析SQL，第一版往往能跑，但跑得慢。慢在哪？我总结下来，90%的情况是扫描了太多不需要的数据。所以性能优化的优先级里，第一位永远是“减少扫描量”。

最有效的办法是用好分区和谓词下推。如果你的表按日期分区，WHERE里一定要写时间范围，比如created_at >= '2025-01-01' AND created_at < '2026-01-01'，这个条件会让引擎直接裁剪掉不相关的分区，扫描量可能下降一个数量级。很多人写SQL不写日期范围，或者把日期函数套在分区列上，比如WHERE DATE(created_at) = '2025-06-01'，这会导致引擎无法裁剪分区，被迫全表扫描。

把过滤条件尽量写在子查询里而不是外层也是同理。比如：

sql复制-- 不推荐的写法：先关联再过滤
SELECT ...
FROM orders o
JOIN users u ON o.user_id = u.user_id
WHERE o.created_at >= '2025-01-01';

-- 推荐的写法：先过滤再关联
SELECT ...
FROM (SELECT * FROM orders WHERE created_at >= '2025-01-01') o
JOIN users u ON o.user_id = u.user_id;

大多数SQL引擎的谓词下推优化器都能自动处理这种逻辑，但在复杂多层子查询里，显示地把过滤条件往里写更保险。跟数据库打交道，永远不要赌优化器一定聪明。

5.2 聚合下推与“先窄后宽”原则

两个表做JOIN之后再聚合，和先聚合再JOIN，结果通常相同但性能差距很大。多维分析SQL里应当尽量“先窄后宽”：先把每个维度表或明细表聚合到所需粒度，再和其他表做关联。这样JOIN之前数据量已经大幅减小。

举个例子，你要算每个渠道的GMV和每个渠道的广告费用。最笨的写法是先把订单明细JOIN广告表，再GROUP BY渠道；更优的写法是分别在订单表和广告表上按渠道聚合，最后再JOIN两个聚合结果。后者在百万行订单和十万行广告数据下，差距可能就是几百毫秒和几秒。

这条原则也解释了为什么要善用WITH子句。它让你的SQL结构更清晰，也便于优化器在各个CTE上分别做聚合下推。注意，WITH子句在部分引擎里不是物理物化，只是逻辑复用，不能保证“只算一次”，但整体依然利于写清楚。

5.3 临时表与物化：什么时候值得多写一步

多维分析SQL如果特别复杂，比如一层嵌套套一层嵌套，直接改写成临时表往往能大幅提速。原因在于：中间表可以复用、可以加索引、可以分区，而且每层计算都落盘，查询引擎不用反复计算同一个子查询。

我自己的经验判断标准是：

子查询被多个地方引用，改写临时表。
子查询计算很重（比如大表DISTINCT、多个JOIN），但结果集很小（比如只有几万行），改写临时表。
一个SQL超过三层嵌套，或超过20个JOIN，拆成临时表。
只是简单的过滤和分组，没必要拆，直接写。

举个例子，做用户留存分析时，“目标用户集合”会被反复关联，我通常把它先物化成临时表，再在上面建索引，后续SQL直接读临时表，速度提升非常明显。直接写一个复杂SQL跑十分钟，拆成三步每步一两分钟搞定，还更容易排查问题，这个账一定得算清楚。

6. 多维分析SQL的经典坑位与判断方法

6.1 执行顺序：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → 窗口函数

窗口函数写错，十有八九是搞混了执行顺序。一条SQL的逻辑执行顺序大致是：

FROM：确定数据源，完成JOIN
WHERE：过滤行
GROUP BY：分组
HAVING：过滤分组
SELECT：计算表达式、聚合
窗口函数：在SELECT阶段或其后处理，基于分组结果计算
ORDER BY：排序
LIMIT：截断

这意味着三件事：

WHERE里不能直接用聚合函数，因为WHERE执行时GROUP BY还没跑。
HAVING里可以用聚合结果，因为HAVING在GROUP BY之后。
窗口函数是在GROUP BY之后执行的，所以在窗口函数里可以用SUM(amount)引用聚合结果，但如果你想在WHERE里过滤窗口函数的结果，必须包一层子查询。

记住这条执行顺序，能少踩一半的语法和逻辑坑。

6.2 COUNT(DISTINCT)的高基数陷阱

COUNT(DISTINCT user_id)在数据量小的时候没问题，但当user_id的基数达到千万级别、表行数达到亿级时，精确去重的计算代价会非常恐怖，因为它需要维护一个巨大的哈希集合。多维分析里如果这种去重指标还和多个维度做GROUP BY，代价是翻倍的。

替代方案有三个：

用近似去重函数，比如Hive的approx_count_distinct、ClickHouse的uniqCombined、Spark的approx_count_distinct。
提前在每日ETL里算好用户维度的汇总表，再在上层做多日合并。
用位图存储用户ID集合，做OR/AND运算，适合留存、活跃类分析。

我见到过真实案例：一条带COUNT(DISTINCT)的日活SQL跑了40分钟，改成位图后10秒内出结果。SQL写法的选择，直接决定一次分析任务的效率。

6.3 空值与汇总行混在一起的判定

前面2.4节已经讲过GROUPING()，这里再补充一个容易混淆的场景：有时候你在GROUP BY后用COUNT(column)统计非空值数量，如果列里有NULL，这个计数会把这些行排除。如果你本意是“统计这个维度下有多少订单”，应该用COUNT(*)，而不是COUNT(order_id)。

很多人习惯用COUNT(字段)来“严谨地”统计非空值，但在多维分析场景下反而容易误导。我的习惯是：统计行数一律用COUNT(*)，统计“某个字段有值的行数”才用COUNT(字段)，需要统计唯一值再用COUNT(DISTINCT)。三种语义不能混用。

6.4 别用列序号代替列名

GROUP BY 1 ORDER BY 2这种写法在某些数据库里能跑，而且写起来确实快。但它的可读性和可维护性非常差：你改了SELECT里的列顺序，整个分组的语义就变了，而且别人看你的SQL完全不知道按哪个字段分组。

我接手过一个SQL，SELECT里有八个字段，GROUP BY 1,2,3,4,5,6,7,8，没有一个人敢动它，因为谁都不知道第4列到底是什么。后来我花了半小时把它改写成GROUP BY column_name，才让这条SQL变得可维护。写代码不只是写给机器执行，更是写给人看的，这一点在多维分析SQL里尤其重要。

7. 多维分析SQL里那些“看似一样，实际天差地别”的写法

GROUP BY和窗口函数都能做“分组计算”，但适用范围完全不同。GROUP BY把多行压成一行，窗口函数保持行数不变、为每行附加一列计算值。用错的话，结果差别非常直接。

sql复制-- GROUP BY：每渠道一行
SELECT channel, SUM(amount) FROM orders GROUP BY channel;

sql复制-- 窗口函数：每行保留，但附加渠道总GMV
SELECT order_id, channel, amount, 
       SUM(amount) OVER (PARTITION BY channel) AS channel_gmv
FROM orders;

前者适合“结果集就是汇总表”的场景，后者适合“明细上带汇总字段”的场景，典型的应用是“明细列表里同时展示该笔订单所在渠道的总GMV，方便对比单笔和渠道整体的关系”。两种场景在业务里都用得上，但如果选错了，就会出现明明要10行结果却返回了100万行明细，或者明明要明细却把数据压缩成了一行汇总。

还有一个容易混淆的点是HAVING和WHERE。WHERE在分组前过滤行，HAVING在分组后过滤组。如果你要“只看GMV大于100万的渠道”，一定要写成HAVING SUM(amount) > 1000000，不能用WHERE SUM(amount) > 1000000，因为WHERE执行时SUM还没算出来。反过来，如果你要“只看2025年的订单”，这个条件一定要放到WHERE里，不要放到HAVING里，因为前者能提前缩小扫描范围，性能好得多。

8. 多维分析SQL的日常修炼：怎么练才有效

说句实话，SQL这门技能靠看手册学不会，一定得靠写。但漫无目的地写也进步慢。我自己带新人时的做法是：从业务问题出发，倒推SQL需求，而不是从语法出发背公式。

具体可以这样做：找一张你工作里最常用的明细表，给自己出题：

每天、每周、每月的GMV趋势
每个渠道、每个品类的TopN
每个用户的首单时间分布
每个商品从曝光到收藏到购买的行为转化漏斗
每个地区的复购率变化

每道题都用两种写法各做一遍：一种用GROUP BY + 子查询，一种用窗口函数。对比执行计划和结果，你很快就能体会到哪种写法在处理什么数据量时更优。这个过程坚持一两个月，多维分析SQL的敏感度会明显不一样。

还有一件事值得专门练习：把一张宽表的数据用SQL“透视”成一张交叉表。比如“行是月份，列是渠道，值是GMV”，这种需求在Excel里是透视表，在SQL里就需要用条件聚合（CASE WHEN + SUM）来实现。练习这类写法对理解维度、度量的关系特别有帮助。

sql复制SELECT DATE_FORMAT(created_at, '%Y-%m') AS month,
       SUM(CASE WHEN channel = 'app' THEN amount ELSE 0 END) AS app_gmv,
       SUM(CASE WHEN channel = 'web' THEN amount ELSE 0 END) AS web_gmv,
       SUM(CASE WHEN channel = 'mini_program' THEN amount ELSE 0 END) AS mini_gmv,
       SUM(amount) AS total_gmv
FROM orders
WHERE created_at >= '2025-01-01'
  AND created_at < '2026-01-01'
GROUP BY DATE_FORMAT(created_at, '%Y-%m')
ORDER BY month;

这种“行转列”的写法在业务报表里特别常见，也是多维分析SQL从“能跑”走向“好用”的一个标志。

最后分享一个我个人的小习惯：每写完一条复杂的多维分析SQL，我都会问自己三个问题——结果对不对？数据量再涨十倍还能不能跑完？新人接手能不能看懂？如果三个答案都是肯定的，这条SQL才算真正合格。你在实际工作中遇到的业务场景，大概率比我写的这些例子更复杂，但底层逻辑永远是同一套：想清楚维度、度量、粒度，然后用合适的语法把这个组合表达出来。