公用事业费用的阶梯计费，核心难点不在于SQL语法本身，而在于如何正确地“逐行累计”。很多人一开始想到用GROUP BY把用户和月份一聚合，然后对着总用量套阶梯——这基本是条死路，因为你根本看不出哪部分用量属于哪个阶梯段位。正确的做法是：用窗口函数按用户+时间排序，计算截至当前行的累计用量，再基于累计值匹配阶梯区间。语法上就是 SUM(usage) OVER (PARTITION BY user_id ORDER BY billing_date, id ROWS UNBOUNDED PRECEDING)，再用 CASE WHEN 判断累计量落在哪个档。注意这里的 ROWS UNBOUNDED PRECEDING 是必须的，否则默认窗口范围可能只包含同一月份的数据，那就等于白做。

阶梯计费需要按用户+月份排序累计用量，别直接用 SUM() 聚合

公用事业（水/电/燃气）阶梯计费的核心是：同一用户在某计费周期内，用量分段计价（比如0–10m³按2元/m³，10–20m³按2.5元/m³）。关键不是总用量，而是“当前行累计到多少”，这必须用窗口函数实现。直接写 SUM(usage) GROUP BY user_id, month 会丢失分段依据——你根本不知道哪部分用量落在哪个阶梯里。

正确做法是先按用户、时间排序，再用 SUM(usage) OVER (PARTITION BY user_id ORDER BY billing_date ROWS UNBOUNDED PRECEDING) 计算截至当前账单的累计用量。注意：ROWS UNBOUNDED PRECEDING 是必须的，否则默认范围可能只包含同月数据，导致阶梯误判。

• 确保 billing_date 是精确到天的时间戳，而非仅月份字符串——否则排序不稳定，同月多条记录顺序不可控
• 若存在补录或冲正账单，需在 ORDER BY 中加入唯一字段（如 id）防并列排序歧义
• MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持该语法；SQLite 3.25+ 可用但性能较差

用 CASE WHEN + 窗口累计值匹配阶梯区间

拿到每条记录的累计用量后，不能用子查询或 JOIN 查阶梯表——那样会爆炸式关联。应把阶梯规则硬编码进 CASE WHEN，用累计值判断归属区间。例如三档阶梯：

SELECT *,  CASE     WHEN cum_usage <= 10 THEN cum_usage * 2.0    WHEN cum_usage <= 20 THEN 10 * 2.0 + (cum_usage - 10) * 2.5    ELSE 10 * 2.0 + 10 * 2.5 + (cum_usage - 20) * 3.0  END AS tiered_amountFROM (  SELECT *,    SUM(usage) OVER (      PARTITION BY user_id       ORDER BY billing_date, id       ROWS UNBOUNDED PRECEDING    ) AS cum_usage  FROM bills) t;

注意：这里计算的是「当前账单结束后的总费用」，不是单期费用。要拆出本期费用，得用 cum_usage - LAG(cum_usage, 1, 0) OVER (...) 得到本期用量，再套阶梯逻辑。

• 阶梯单价和阈值必须与业务方确认是否含边界（<= 还是 <），水电常含等号，燃气可能不含
• 如果阶梯规则频繁变更，建议把阶梯表单独建模，用 JOIN LATERAL（PostgreSQL）或相关子查询动态匹配，但性能明显下降
• LAG() 的默认值设为 0，避免首条记录返回 NULL 导致本期用量计算失败

处理跨年/跨周期重置：用 RESET WHEN 或重构 PARTITION BY

很多地区阶梯按自然年重置（每年1月从0开始累计），但也有按抄表周期（如每2个月）重置。窗口函数本身不支持“遇到新年就清零”，必须靠 PARTITION BY 拆分范围。

若按年重置：PARTITION BY user_id, YEAR(billing_date)；若按抄表周期，则需生成虚拟周期字段，例如：

EXTRACT(YEAR FROM billing_date) * 100 +   CEIL(EXTRACT(MONTH FROM billing_date) / 2.0) AS cycle_id

然后 PARTITION BY user_id, cycle_id。别试图用 RESET WHEN（仅 Oracle 12c+ 支持且语法复杂），多数数据库没这功能。

• PostgreSQL 可用 generate_series() 预生成周期维度表辅助关联，但增加ETL复杂度
• MySQL 用户注意：YEAR() 函数对 DATETIME 安全，但对 VARCHAR 类型日期会隐式转换失败
• 测试时务必覆盖“12月账单+次年1月账单”场景，验证累计值是否真的被重置

性能陷阱：窗口函数在大数据量下容易内存溢出

当用户数超百万、账单记录过亿时，SUM(...) OVER (PARTITION BY user_id ORDER BY ...) 可能触发 sort-based window aggregation，占用大量内存甚至 OOM。PostgreSQL 的 work_mem、MySQL 的 sort_buffer_size 都需针对性调优。

• 加复合索引：(user_id, billing_date, id) —— 顺序不能错，前两列用于分区+排序，第三列解决并列
• 避免在窗口函数里嵌套复杂表达式（如 COALESCE(usage, 0)），先在子查询中清洗干净
• 生产环境首次运行前，用 LIMIT 1000 验证逻辑，再逐步放开；切勿直接全量跑

阶梯计费真正的难点不在 SQL 语法，而在业务规则的歧义点：起始日怎么定、退补怎么折算、多户合表如何分摊——这些都得靠上游数据质量兜底，SQL 只负责精准执行已确认的规则。