窗口函数需用SUM() OVER配合PARTITION BY user_id ORDER BY billing_date, id ROWS UNBOUNDED PRECEDING计算累计用量，再通过CASE WHEN或JOIN阶梯表匹配分段区间，不可用ROW_NUMBER()、RANK()、NTILE()或WIDTH_BUCKET()替代，因其无法处理累进计费所需的用量切片与跨段叠加。
窗口函数怎么配合阶梯计费的分段逻辑
直接用 ROW_NUMBER() 或 RANK() 解决不了阶梯计费——它们只管排序，不管区间匹配。真正需要的是把每条记录映射到对应的价格区间，这得靠 JOIN 阶梯表 + 窗口函数辅助计算累计量，或者用 CASE WHEN 搭配 SUM() OVER 做动态累加判断。
典型场景：用户月度用量按 0–100GB、101–500GB、501+GB 三档计费，每档单价不同，且费用需累进（不是全量按最高档算）。这时候不能只看当前用量，得知道“前一段用了多少、剩多少进下一段”。
- 必须先对原始用量数据按用户+时间排序，用
LAG()或SUM() OVER (ORDER BY ...)算出已消耗的累计值 - 阶梯规则建议单独建表（
pricing_tiers），含min_usage、max_usage、unit_price，避免硬编码 - 注意边界：区间是闭-开还是闭-闭？
BETWEEN包含两端，但累进计费通常要拆解为“本段有效用量 = MIN(当前累计, 本段上限) - MAX(上段累计, 本段下限)”
用 SUM() OVER 实现逐段用量剥离
核心思路是把总用量“切片”：对每个阶梯，算出该段实际被占用的用量。这需要两层窗口计算——外层算用户总用量，内层用 SUM() OVER (ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) 做逐行累计，再和阶梯上下界比较。
常见错误是直接在 WHERE 里过滤阶梯，结果只能算单段；或用 GROUP BY 提前聚合，丢失了逐条记录的阶梯归属。
- 先用
SUM(usage) OVER (PARTITION BY user_id ORDER BY month)得到截至当月的累计用量 - 再用
LAG(cumulative_usage, 1, 0) OVER (PARTITION BY user_id ORDER BY month)拿到上月累计，差值就是本月新增用量 - 对每条记录，用
CASE判断新增用量落在哪几段：比如累计到 120，上月累计 80，则 80→100 这段按第一档、100→120 按第二档
为什么不能只用 NTILE() 或 WIDTH_BUCKET()
NTILE() 是等份分桶，WIDTH_BUCKET()（Oracle/PostgreSQL）虽支持自定义边界，但只返回桶号，不提供区间内用量、也不支持累进叠加。它适合“打标签”，不适合“算钱”。一旦计费规则变成“前100免费，101–200收1元/GB，201+收2元/GB”，WIDTH_BUCKET() 返回的只是“属于第2桶”，没法自动拆出 101–200 用了多少、201+ 又用了多少。
-
NTILE(3)把数据强行分成3组，和业务阶梯完全无关，用量10GB和99GB可能被分进同一组 -
WIDTH_BUCKET(usage, 0, 500, 3)能分出 0–166、167–333、334–500，但无法处理跨段情况（如用量450，需同时触发第二档和第三档） - 真正要的是“用量切片器”，不是“分组器”——必须结合
LEAST()、GREATEST()和窗口累计值做运算
PostgreSQL/MySQL 8.0+ 兼容写法要注意什么
MySQL 8.0+ 支持标准窗口函数，但不支持 RECURSIVE CTE 做阶梯展开；PostgreSQL 可用 generate_series() 辅助，但生产环境更推荐用 JOIN 阶梯表。两者都需警惕 NULL 处理：当累计用量未达第一档下限时，GREATEST(cumulative_usage, tier_min) 会失效，得补 COALESCE。
- MySQL 中
LAG()第二参数不能设默认值（如LAG(x, 1, 0)会报错），得用COALESCE(LAG(x) OVER (...), 0) - PostgreSQL 的
WIDTH_BUCKET()边界是左闭右开，而计费常用左闭右闭，需手动调整max_usage + 1 - 所有涉及
SUM() OVER的字段，务必确认ORDER BY子句存在且唯一（加user_id, month联合排序），否则累计结果不可靠
阶梯计费最易被忽略的点：没区分“单次用量”和“累计用量”。很多实现只看了当月用量，忘了阶梯是基于历史总用量滚动生效的——这个逻辑偏差会导致整张账单错乱，而且上线后很难回溯修正。
