对比PostgreSQL执行计划判断分区最优尺寸有哪些参考参数？

仅以执行时间作为判断最优分区方案的标准是不合理的。执行时间是最终性能的直观体现，但单次执行结果容易受服务器负载、缓存命中、后台任务等随机因素干扰，且无法反映长期运维、数据增长后的潜在性能风险，需要结合多维度参数综合评估。

核心评估参数 #

执行计划维度 #

• 规划时间：分区数量越多，查询规划器遍历所有分区判断是否需要扫描的耗时越长。单条查询的规划时间差值可能只有几毫秒，但高并发场景下累积的开销会非常可观，是容易被忽略的核心指标。
• 实际扫描分区数：检查EXPLAIN ANALYZE输出中扫描的分区列表，确认分区剪枝逻辑是否正常生效。理想情况下等值、范围查询应当只扫描命中的少量分区，如果出现全分区扫描的情况，哪怕单次执行时间短，数据量增长后性能会出现骤降。
• 扫描行数与返回行数差值：如果单分区扫描后需要过滤的行数占比过高，说明分区键选择或者分区粒度存在问题，即便当前执行时间达标，后续数据增长后也会快速出现性能瓶颈。
• 锁等待时长：分区粒度越小，单分区的数据量越少，写入、更新操作的锁影响范围越小。高并发写入场景下需要额外关注EXPLAIN ANALYZE输出中的锁等待时间，也可以同步测试并发写入的吞吐量、超时率指标。

运维成本维度 #

• 分区管理成本：如果是按时间分区，分区尺寸过小会导致分区数量爆炸，例如日分区存储10年数据就会产生3650+个分区，日常备份、历史数据清理、元数据维护的成本会大幅上升，甚至会影响PostgreSQL系统表的查询性能。
• Vacuum执行效率：单分区尺寸过大时，Vacuum扫描单分区的耗时会很长，容易出现死元组堆积、表膨胀的问题；单分区尺寸过小时，Vacuum需要处理的分区数量过多，也会占用过多系统资源。
• 存储空间开销：不同分区粒度下的表膨胀率、索引大小会存在差异，需要对比相同数据量下三种方案的总存储空间占用，包括表本体和所有关联索引的大小。

扩展性维度 #

• 数据增长适配性：模拟未来1-3年的数据增长情况，测试当前分区方案在数据量翻倍、翻3倍后的性能表现，不能仅参考当前数据量下的执行时间。
• 全场景查询适配性：除了日常的慢查询，还要覆盖所有不常用的批量查询、报表查询、运维类查询的执行情况，避免出现常规查询性能优异，但少数批量查询完全无法运行的问题。

测试注意事项：每次测试前建议清空缓存（测试环境可执行echo 3 > /proc/sys/vm/drop_caches操作），多次执行查询取p50、p95、p99分位的执行时间，不要仅参考单次或者平均执行时间，尽可能排除环境干扰。

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