正确写法需显式指定 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 并用唯一键（如 id）消除并列，再通过 CTE + JOIN 阶梯表实现动态阈值匹配。
窗口函数在积分阶梯计算中几乎是绕不开的工具，但很多人一上来就写 SUM(points) OVER (ORDER BY score)，结果数据一跑，发现累计值跟自己预期完全对不上。问题出在哪？往往就出在那个隐式的 RANGE 模式上。如果排序字段有重复值，数据库会把这些行“捆在一起”算总和——同一分数可能对应多个不同的累计值，这显然不是我们想要的。
窗口函数怎么写才能正确累积积分？
直接用 SUM() 加 OVER(ORDER BY ...) 很容易出错——如果排序字段有重复值，MySQL 8.0+ 和 PostgreSQL 会非确定性地累积，导致同一分数对应多个不同累计值。必须显式指定 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，否则默认是 RANGE 模式，对相同 score 的行会“捆在一起”算总和。
- 错误写法：
SUM(points) OVER (ORDER BY score)（隐式 RANGE，危险） - 正确写法：
SUM(points) OVER (ORDER BY score, id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)（加唯一键防并列） - 若业务允许同分同阶梯，且需严格按录入顺序，则用
ROW_NUMBER()或自增id作为第二排序键
阶梯阈值怎么动态匹配当前累计积分？
窗口函数只负责算出累计值，不自动做区间判断。常见做法是把窗口结果当子查询，再用 CASE WHEN 或 JOIN 查阶梯表。别在窗口里嵌套 CASE 去比对硬编码阈值——一旦阶梯规则变，SQL 就得重写。
- 推荐结构：先用 CTE 算出
cumulative_points，再LEFT JOIN到阶梯配置表（如tier_rules），条件为t.cumulative_points >= r.min_points AND t.cumulative_points < r.max_points - 注意：阶梯表必须保证区间不重叠、无空隙，否则
JOIN可能漏行或匹配多行 - 若阈值极少变动，也可用
VALUES构造临时阶梯（PostgreSQL）或UNION ALL（MySQL），避免建表
用户积分清零后如何重置阶梯？
窗口函数默认跨整个结果集排序，无法感知“用户维度”的重置边界。必须用 PARTITION BY user_id，否则张三的积分会被李四的数据带偏。
- 关键点：
OVER (PARTITION BY user_id ORDER BY event_time ROWS UNBOUNDED PRECEDING) - 时间戳字段
event_time必须非空且唯一，否则仍需加id辅助排序 - 清零操作本质是一条
points = -999999的记录，靠排序位置自然拉低后续累计值；不要试图在窗口里用RESET WHEN（目前仅 Snowflake 支持）
为什么 ORDER BY 字段加索引后性能还是差？
窗口函数执行时会强制 materialize 排序结果，即使 user_id + event_time 有联合索引，PARTITION BY user_id ORDER BY event_time 仍可能触发临时表和 filesort。尤其当单用户事件超 10 万条时，累计计算变成瓶颈。
- 优化方向：对高频查询用户，预计算每日/每周累计快照存到物化视图（PostgreSQL）或汇总表（MySQL）
- 避免在 WHERE 中过滤后再开窗口——先
WHERE再WINDOW，否则引擎仍要扫描全分区 - PostgreSQL 15+ 支持
WINDOW子句复用，可减少重复排序；MySQL 8.0 目前每个窗口独立排序，慎用多个窗口函数
真正麻烦的是阶梯规则变更后的历史重算——窗口函数本身不存状态，每次查询都实时算，没缓存就只能扛住压力或提前走汇总表。从实践来看，预计算 + 定期刷新是更稳的方案，尤其在用户量大的场景下，别让生产环境等着一行一行算累计。
