所有分区均衡使用时PostgreSQL UUID范围分区能否提升性能？

先给明确结论：你描述的这套分区方案，对你列的两类查询场景都不会带来性能提升，第二类全分区扫描场景反而会明显劣化性能。

1. 基于UUID的单行等值查询（WHERE uuid_key = :id） #

这类查询性能基本和未分区的单表持平，不会有可观测的性能提升，极端情况下还会有小幅劣化。

• PostgreSQL的分区裁剪机制确实能在这类查询里直接定位到唯一的目标分区，不需要扫描其余255个分区，不会出现全分区扫描的额外开销。
• 拆成256个分区后，每个分区的本地主键B树索引体积确实比单表的全局主键索引小，理论上索引树高度可能降低1层，单步索引查找的开销略降，但这部分收益会被分区路由的固定开销完全抵消：数据库需要先计算传入UUID对应的分区范围，再访问对应分区的元数据、调取分区索引，这部分额外的计算和元数据访问成本，刚好盖过小索引带来的微弱收益。
• 由于所有分区都在同一块物理磁盘上，没有多盘并行IO、热点分区落高速存储的优化空间，单行查询需要的随机IO延迟和单表场景完全一致，没有额外优化空间。

2. 需要扫描全部分区的查询 #

这类场景性能一定会比单表更差，不存在性能提升的可能。

• 执行计划生成阶段，优化器需要为256个分区分别生成扫描路径、计算成本，规划耗时会比单表高一个量级，分区数量越多这部分开销越明显。
• 执行阶段如果是串行扫描，数据库需要逐个打开、扫描每个分区，再把所有分区的返回结果做合并，比单表直接顺序扫描多了一层分区切换、结果合并的开销。如果开了并行扫描，由于所有分区都在同一块物理磁盘上，多个并行worker同时读不同分区，会把原本单表顺序读的IO模式变成跨分区的随机寻道读，而机械盘/固态盘的顺序读性能本来就远高于随机读，这部分IO开销的上涨会直接拉低整体查询速度。
• 如果查询带聚合、排序、关联操作，分区场景下还需要先对每个分区的中间结果做局部处理，再做全局的二次聚合/归并排序，比单表直接处理全量数据多了一层计算开销。

补充说明 #

这套分区方案唯一的收益不在查询侧，而在数据运维侧：如果后续需要按UUID范围做批量数据删除、归档，直接DROP TABLE删除对应分区的速度，比单表场景下走DELETE批量删除数据快几个数量级，也不会产生大量表膨胀问题，但这不属于查询性能提升的范畴。

内容的提问来源于stack exchange，提问作者Flavien