阶梯电价计算不能只用group by，因其会压缩行数而丢失逐条记录的累计用量和档位单价；必须用窗口函数sum() over(partition by user_id, year_month order by read_time)计算累计用电量，再通过case按档位边界（含下限、不含上限）匹配单价。
阶梯电价计算为什么不能只用 GROUP BY
因为阶梯电价需要按用户、月份累计用电量，再根据累计值查对应单价，而 GROUP BY 会压缩行数，丢失逐条记录的“当前累计量”和“本档单价”。窗口函数才是正确解法——它保留原始行，同时支持跨行累加和条件映射。
常见错误是直接对 consumption 字段用 SUM() 聚合，结果每户只出一行，没法给每条抄表记录打上对应档位单价。必须用 SUM() OVER (PARTITION BY user_id, year_month ORDER BY read_time) 算出每条记录截止当时的累计用量。
怎么用 CASE + 窗口 SUM 拆解阶梯档位
核心逻辑是：先算出每条记录的累计用电量，再用 CASE 判断落在哪一档，最后乘以该档单价。注意档位边界是“包含下限、不包含上限”，比如 0–180 kWh（含 0，不含 180）按 0.5 元/kWh，180–280（含 180，不含 280）按 0.6 元/kWh。
-
SUM(consumption) OVER (PARTITION BY user_id, year_month ORDER BY read_time ROWS UNBOUNDED PRECEDING)是累计关键，ROWS UNBOUNDED PRECEDING确保从当月第一条开始累加 - 档位判断必须用
AND连接上下界，例如WHEN cum_consumption >= 0 AND cum_consumption - 如果抄表时间乱序，
ORDER BY read_time失效，务必先清洗时间字段或加唯一排序键（如id）
多档叠加计费（如夏季加价）怎么处理
真实场景中，阶梯档位可能随季节变化。这时不能硬编码 CASE，要把档位规则抽成独立表，用 JOIN 或 LATERAL 关联。否则改个夏天阈值就得改 SQL，维护成本高。
推荐结构：tier_rules 表含字段 season、min_kwh、max_kwh、rate；主表通过 year_month 推断季节（如 EXTRACT(MONTH FROM read_time) IN (6,7,8)），再关联匹配档位。
容易踩的坑：JOIN 时没加 ON r.min_kwh ，导致笛卡尔积；或者漏了 <code>PARTITION BY user_id, year_month 导致跨月累计错乱。
性能瓶颈在哪？怎么避免全表扫描
窗口函数本身不慢，但累计计算在大数据量下容易成为瓶颈，尤其当 PARTITION BY 组太多、每组数据又很长时。最直接的优化是加复合索引：(user_id, year_month, read_time) —— 这能让 OVER 子句的排序和分组走索引，避免临时文件排序。
另一个隐形陷阱：如果 read_time 有大量重复值（比如同一秒多个抄表），ORDER BY read_time 无法保证稳定顺序，累计结果可能每次执行都不一样。必须补一个确定性排序字段，比如自增 id 或 ROW_NUMBER() OVER (...) as seq。
复杂点在于档位不是简单分段，而是“超额累进”（如前 180 度按 0.5，超出部分按 0.6），这时得用更复杂的窗口嵌套或 CTE 拆解每档用量，不能只靠单层 CASE。这个细节常被忽略，直到财务对账时发现电费差了几块钱。
