分区字段应选高基数且分布均匀的字段，避免高基数导致分区数爆炸或低基数引发数据倾斜，同时需考虑引擎差异、索引支持及提前过滤。
分区字段选高基数但不倾斜，不是越细越好
窗口函数性能崩盘，八成是因为 PARTITION BY 字段选错了。它决定数据被切成多少块、每块多大、是否能并行——不是“越细分越准”，而是“切得匀、扛得住、查得快”。
- 高基数 ≠ 高性能：像
user_id这种千万级字段，分区数爆炸，调度开销压垮 Executor；而tenant_id或shop_id通常几百到几千个值，分布稳、内存压力小 - 低基数陷阱：比如
PARTITION BY status（只有 'active'/'inactive'），95% 数据挤进一个分区，变成单点计算瓶颈 - 时间字段要降维：用
date_trunc('day', event_time)比直接event_time（毫秒级）分区更可控；前者一天一个分区，后者可能每秒一个分区 - 检查分布：执行
SELECT partition_col, COUNT(*) FROM t GROUP BY partition_col ORDER BY COUNT(*) DESC LIMIT 5，看头部几个值是否占全量 80% 以上
避免用无索引或重复值多的字段做分区键
数据库对 PARTITION BY 字段本身不要求索引，但没索引时，划分分区边界就得扫全表或排序，WindowAgg 节点旁常跟着 Sort 或 Materialize —— 这是性能拐点。
- 如果分区字段常和
ORDER BY一起用（如PARTITION BY region ORDER BY created_at），必须建复合索引：(region, created_at)，顺序不能错 - 别在表达式上分区：比如
PARTITION BY UPPER(name)，无法走普通索引；函数索引代价高，且多数引擎不支持在窗口中下推 - NULL 值会归为同一组：如果
department_id有大量 NULL，它们全被塞进一个隐式分区，极易倾斜；提前用COALESCE(department_id, -1)处理
Spark 和 PostgreSQL 的分区行为差异要盯住
同一句 SQL，在不同引擎里分区实际效果可能差十倍——尤其 Spark 会把分区字段当 Shuffle key，PostgreSQL 更依赖内存缓存局部排序结果。
- Spark 中，
PARTITION BY user_id会触发 massive shuffle；换成PARTITION BY date_trunc('day', event_time), region后，Shuffle 数据量从 98GB 降到 12GB 是常态 - PostgreSQL 14+ 对
ROWS BETWEEN优化好，但若分区数据超 500 万行，仍会 spill to disk；用EXPLAIN (ANALYZE, BUFFERS)看WindowAgg节点的width和rows是否异常高 - ClickHouse 不走传统分区逻辑，它用
runningAccumulate替代简单累加，但不支持RANK()或带ORDER BY的复杂窗口——别硬套语法
必须提前过滤，别指望窗口函数扛住全量
窗口函数不是过滤器，它是计算层。在亿级表上先 WHERE dt >= '2026-07-01' 再开窗，比全表扫完再分区快一个数量级。
- WHERE 条件能下推到扫描阶段，减少进入 WindowAgg 的行数；而
HAVING或外层WHERE对窗口结果过滤，已经晚了 - CTE 不一定省事：如果 CTE 里算了一次
ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)，外层又用它做 JOIN，某些引擎（如旧版 PG）不会复用，而是重算一遍 - 真正省事的是物化中间表：比如先按天聚合用户行为，生成
daily_user_summary，再在这个小表上开窗——数据量降下来，PARTITION BY user_id才敢用
分区字段选错的后果不是慢一点，而是查询卡死、OOM、shuffle 溢出。最该花时间做的不是调 work_mem 或加节点，而是打开执行计划，盯着 WindowAgg 节点看它到底分了多少区、每区多大、有没有绕过索引。
