一对多关联会把金额炸开

订单头一行一个金额，明细一行一个 SKU。连接后金额若还在头上，SUM 会按明细行复制。分析里叫扇形陷阱。问数里它长得像业绩暴涨。公开文章提醒复杂关联前先描述、抽样、验证键。验证的就是这件事。

金额放在哪一层

在头上就先按头汇总，再连。在明细上就 SUM 明细，不要两边各加一次。

先比行数

连接后行数约等于明细行，金额却像头表乘了一个系数，就是炸了。

一对多要自觉

需要明细维度时，用明细事实；只问订单金额时，不要为了「信息更多」去连。

一次完整的问法可以先写成下面这样：

3 月已支付 GMV 应按订单头汇总，不要连明细再加 pay_amount。

落到语句上，草稿常常是：

SELECT SUM(pay_amount) AS gmv
FROM orders
WHERE pay_time >= DATE '2026-03-01'
  AND pay_time < DATE '2026-04-01'
  AND pay_status = 'paid';

需要按 SKU 时，改用明细上的金额字段，并在卡片上写明。两套金额必须改名，不能都叫 GMV。

语句是收据，默认只读

第一纪律是 SELECT。草稿里出现更新、删除、结构变更，整张收据作废。第二纪律是时间窗。大表没有时间条件，不跑。第三纪律是粒度。GROUP BY 的键必须和问题里的维度一一对应。

一对多关联会把头上的金额按明细复制，看起来像增长，其实是扇形。COUNT 和 COUNT DISTINCT 不是同一指标。NULL 不是 0。日期函数没有世界语，能写绝对区间就写绝对区间。

复杂逻辑用公共表表达式拆开。拆开是为了给人看中间结果。先对再快。用索引去救一条口径错误的语句，会把错误生产化。

读完这一辑可以做什么

把你最近一条问数语句拆成三段 WITH：过滤、聚合、排名。每一段单独跑。有一段解释不清，就回到提问，不要在语句里继续加花样。

金额炸开时长得像增长。先比行数，再相信合计。