阶梯计费必须用窗口函数按用户+时间排序累计用量，而非GROUP BY聚合；正确写法是SUM(usage) OVER (PARTITION BY user_id ORDER BY billing_date, id ROWS UNBOUNDED PRECEDING)，再用CASE WHEN基于累计值匹配阶梯区间，并按年或抄表周期用PARTITION BY重置累计。
阶梯计费需要按用户+月份排序累计用量，别直接用 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_amount
FROM (
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 只负责精准执行已确认的规则。
