分区字段应选高基数且分布均匀的字段，避免高基数导致分区数爆炸或低基数引发数据倾斜，同时需考虑引擎差异、索引支持及提前过滤。

分区字段选高基数但不倾斜，不是越细越好

窗口函数一旦性能掉得厉害，十有八九问题就出在 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 的行数；而 HA VING 或外层 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 节点看它到底分了多少区、每区多大、有没有绕过索引。