PARTITION BY 不一定显著拖慢查询，但易因分区键选择不当、数据倾斜或缺失索引而变慢；其性能劣于 GROUP BY，因需保留全量行并常触发排序，导致内存与IO开销更高。
PARTITION BY 会显著拖慢查询速度吗
不一定，但很容易变慢——关键看分区键的选择、数据分布和底层执行计划。窗口函数本身不强制排序，但 PARTITION BY 通常触发分组内排序或哈希分组，而排序成本随分区大小非线性增长。如果分区键高基数（如 user_id）且每分区数据量小，开销可控；若低基数（如 status IN ('active', 'inactive')）导致单个分区占全表 80%，就可能退化成全局排序。
哪些场景下 PARTITION BY 最容易引发性能问题
常见高风险组合：
- 分区键上无索引，且查询还带
ORDER BY子句（例如ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)），数据库大概率走全表扫描 + 外部排序 - 分区后每组数据量差异极大（倾斜），比如一个
tenant_id = 'legacy'分区含 500 万行，其余几百个租户各几百行，执行器无法并行均摊 - 嵌套使用：多层窗口函数叠加
PARTITION BY（如先按日期分区算累计值，再按地区重分区求排名），中间结果集膨胀严重 - 在大宽表上对未压缩列（如长文本、JSON 字段）做分区，内存/磁盘临时空间消耗陡增
如何验证和缓解 PARTITION BY 的实际开销
别猜，用执行计划说话：
- PostgreSQL：加
EXPLAIN (ANALYZE, BUFFERS)，重点看WindowAgg节点的Actual Total Time和是否出现Sort Method: external merge Disk - MySQL 8.0+：查
EXPLAIN FORMAT=TREE，观察是否有window function下挂filesort或temporary table - SQL Server：看执行计划 XML 中
RelOp Op="Window Aggregate"的EstimateRows是否远超实际，以及是否触发SpillToTempDb
缓解手段优先级：先加覆盖索引（如 (dept_id, salary DESC)），再考虑改写（用 JOIN + 聚合替代部分窗口逻辑），最后才调优资源配置（work_mem / sort_buffer_size）。
PARTITION BY 和 GROUP BY 的性能差异在哪
根本区别在于物化行为：GROUP BY 消减行数，输出聚合后的一行；PARTITION BY 保持原始行数，为每行计算分区上下文值。这意味着：
- 内存压力不同：1000 万行数据按 1000 个组分区，
PARTITION BY需缓存全部原始行 + 窗口状态；GROUP BY可能只保留 1000 行聚合结果 - 索引利用不同：
GROUP BY dept_id能高效用到dept_id索引；但PARTITION BY dept_id ORDER BY hire_date要求联合索引才能避免排序，否则照样慢 - 并行度限制：某些引擎（如旧版 Presto）对窗口函数的分区并行支持弱于聚合，尤其涉及
RANGE帧时
分区键选得随意、又没配好索引，PARTITION BY 就是隐形性能杀手——它不报错，只是让查询从秒级变成分钟级，还很难一眼定位。
