窗口函数必须显式指定 ROWS 范围，否则同分时累计值会错乱；需配合 PARTITION BY user_id、唯一排序键及 CTE 分离阶梯逻辑，避免隐式 RANGE 和硬编码阈值导致的错误。
窗口函数必须显式指定 ROWS 范围，否则同分时累计值会错乱
直接写 SUM(points) OVER (ORDER BY score) 是危险的。MySQL 8.0+ 和 PostgreSQL 默认用 RANGE 模式，遇到相同 score 的多条记录，会把它们“捆在一起”求和，导致同一积分值对应多个不同累计结果。
正确做法是强制使用行模式，并引入唯一键破除并列：
SUM(points) OVER (ORDER BY score, id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)- 若业务允许同分同阶梯且依赖录入顺序，可用自增
id或ROW_NUMBER()作第二排序键 - 千万别省略
ROWS子句——隐式RANGE在阶梯计算中几乎必然出错
PARTITION BY user_id 是用户级重置的前提，漏写就全表混算
积分清零、等级重置都发生在用户维度。如果没写 PARTITION BY user_id，张三的第 5 条记录会累加李四前 3 条的积分，结果完全不可信。
关键约束：
OVER (PARTITION BY user_id ORDER BY event_time ROWS UNBOUNDED PRECEDING)-
event_time必须非空且尽量唯一；仍有重复时，务必补上id防止排序抖动 - 清零操作应体现为一条
points = -999999的记录，靠排序位置自然拉低后续累计值，不要幻想RESET WHEN（仅 Snowflake 支持）
阶梯匹配不能硬编码在窗口里，得用 JOIN 或 CTE 分离逻辑
窗口函数只负责算出 cumulative_points，不负责判断属于哪一级。把 CASE WHEN 嵌在 OVER 里写阈值，等于把业务规则锁死在 SQL 中，改个门槛就得重发上线。
推荐结构清晰、可维护的写法：
- 先用 CTE 算出带累计值的结果集：
WITH t AS (SELECT ..., SUM(...) OVER (...) AS cum_points FROM ...) - 再
LEFT JOIN到阶梯配置表tier_rules，条件为t.cum_points >= r.min_points AND t.cum_points < r.max_points - 阶梯表必须保证区间无重叠、无空隙，否则
JOIN可能漏行或多匹配 - 若阈值极少变动，可用
VALUES（PostgreSQL）或UNION ALL（MySQL）构造临时阶梯，避免建表
floor(积分/1000) 这类分段统计适合静态快照，不适合动态等级判定
FLOOR(ValidGold / 1000) 或 FLOOR(ValidGold / 1000 + 1) * 1000 适用于做分布统计（比如“每 1000 分一段的人数”），但它输出的是固定区间标签，无法表达“累计达 30000 才升青铜”的时序依赖逻辑。
真正做等级判定时要注意：
- 它不关心事件顺序，也不支持按用户重置，纯静态分桶
- 不能替代
PARTITION BY + ROWS的累积逻辑 - 若用于报表快照（如每日会员等级快照），可配合
GROUP BY user_id和最大累计值取最后状态，但不是实时等级推导手段
最易被忽略的点：单用户事件超 10 万条时，PARTITION BY user_id ORDER BY event_time 即使有索引也大概率触发 filesort 和临时表。高频查询建议预计算每日累计快照存入汇总表，别每次实时算。
