正确写法需显式指定 rows between unbounded preceding and current row 并用唯一键（如 id）消除并列，再通过 cte + join 阶梯表实现动态阈值匹配。
窗口函数怎么写才能正确累积积分？
直接用 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 - 注意：阶梯表必须保证区间不重叠、无空隙，否则
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 目前每个窗口独立排序，慎用多个窗口函数
真正麻烦的是阶梯规则变更后的历史重算——窗口函数本身不存状态，每次查询都实时算，没缓存就只能扛住压力或提前跑批。
