窗口函数性能差主因是PARTITION BY字段选错；应选高基数且稳定的字段如tenant_id，避免user_id等倾斜字段，必要时预聚合，并优先用ROWS而非RANGE。
窗口函数慢到卡住？先看分区键选对没
窗口函数性能崩盘，八成是因为 PARTITION BY 字段选错了——不是越细越好，也不是越宽越稳。它直接决定数据分片粒度和内存中排序/聚合的范围。
常见错误现象：OVER (PARTITION BY user_id ORDER BY event_time) 在亿级日志表里跑几分钟不出结果；换成 PARTITION BY date_trunc('day', event_time) 后秒出。
- 优先选高基数但业务语义稳定的字段（比如
tenant_id、shop_id），避免用user_id这种可能倾斜的字段做主分区 - 如果必须按
user_id计算，加一层预聚合：先按天汇总用户行为，再在小表上开窗 - PostgreSQL 14+ 和 ClickHouse 支持
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW的高效实现，但 MySQL 8.0 对大窗口仍会落磁盘，慎用RANGE模式
ORDER BY 后面跟了多个字段，为什么结果还是乱的
ORDER BY 在窗口定义里不是“保证最终输出顺序”，只是定义窗口内计算顺序。它不改变查询整体返回顺序，也不解决重复值导致的非确定性。
使用场景：需要累计求和、移动平均、排名去重等依赖严格序的计算。
- 如果
ORDER BY字段存在大量重复（比如都用created_at，精度只到秒），必须补一个唯一字段，如ORDER BY created_at, id - 在 Hive/Trino 中，
ORDER BY缺失或不明确会导致ROW_NUMBER()结果每次执行都不一样 - ClickHouse 的
runningAccumulate函数不依赖ORDER BY，但仅适用于简单累加，不能替代通用窗口逻辑
内存爆了（OOM）或者 spill to disk，怎么调
窗口函数本质是缓存分区数据做局部计算，内存不够就会写临时文件，一慢再慢。关键不是调大内存，而是缩小单个分区的数据量。
性能影响：分区数据量 > 100 万行时，多数引擎开始明显减速；> 500 万行基本触发 spill。
- 检查
EXPLAIN ANALYZE输出里的WindowAgg节点，看width（平均每行宽度）和rows（预估行数）是否异常高 - 用
WHERE提前过滤，比在窗口里硬扛更有效——比如先筛出近 30 天数据，再开窗，别全表扫 - 在 Spark SQL 中，设置
spark.sql.windowExec.buffer.spill.threshold可控 spill 行为，但治标不治本；根本解法仍是减少PARTITION BY内数据规模
不同数据库对 RANGE 和 ROWS 的支持差异很要命
写一次 SQL 想跨库跑通？别信。RANGE 语义在各引擎里要么不支持，要么行为不一致，尤其涉及时间字段时。
错误现象：ROWS BETWEEN 7 PRECEDING AND CURRENT ROW 在 PostgreSQL 正常，在 PrestoDB 报错 “RANGE not supported for non-numeric types”；而 RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW 在 BigQuery 可用，在 Redshift 直接语法报错。
- 能用
ROWS就别碰RANGE：数值偏移稳定、兼容性好、性能可预期 - 时间范围滑动窗口，统一转成序列号处理：生成
date_seq = DATEDIFF(event_date, '2020-01-01')，再用ROWS BETWEEN 6 PRECEDING AND CURRENT ROW - MySQL 8.0 不支持
RANGE时间间隔，且LAG/LEAD默认不支持IGNORE NULLS，得靠变量模拟
分区策略不是配置项，是数据建模的一部分。同一个字段，在明细层做分区可能爆炸，在汇总层却刚刚好。没想清楚业务边界就写 PARTITION BY，后面所有优化都是徒劳。
