空间分区要让裁剪条件与数据分布保持一致

分区把一个逻辑表拆为多个物理子表。查询条件能确定只涉及少数分区时，数据库可以裁剪其余数据，减少扫描和维护范围。空间数据是否受益，取决于查询模式、对象分布和分区键，而不是表是否足够大。

分区键应来自高频过滤

时间序列常按日期范围分区，因为查询和归档都以时间窗口进行。行政区、数据源或固定网格也可作为列表或范围键。若查询从不包含分区键，数据库仍可能访问大量分区。

纯经纬度二维范围不容易直接映射到一维范围分区，可用稳定网格编码、区域标识或计算列。编码必须固定版本，并处理跨网格对象。为了分区而复制对象会改变计数语义。

时间与空间组合可先按月再按区域，但层级过多会产生大量子表。设计应以实际裁剪收益、写入路由和运维成本验证。

点可按所在网格唯一归属，线和面可能跨多个区域。按质心归属保持单份记录，却使相交查询需要访问邻区；切分几何可提高局部查询，但必须保存原对象身份和重组规则。

复制到所有相交分区便于读取，却要求去重并同步更新。不同策略适合不同用途，不能把存储分片后的片段当成独立业务对象。

全球数据还要处理日界线、极区和无效范围。分区函数与查询构造必须使用相同坐标约定。

PostgreSQL 根据分区约束和查询条件排除无关分区。条件若被复杂函数包裹、类型不一致或只在空间谓词内部，优化器可能无法推导分区键范围。

应用可先从查询包围盒计算网格或区域集合，再同时提交分区条件与精确空间谓词。这个计算要保守，宁可多读候选，不能漏掉真实相交对象。

用 EXPLAIN 检查实际访问分区，比假设裁剪发生更可靠。参数化查询、预备语句和运行时裁剪行为应按数据库版本测试。

分区只减少表范围，不替代 GiST 等空间索引。分区内仍需按空间谓词、时间和业务字段建立局部索引。索引数量会增加写入和维护成本。

局部统计可能更准确地描述区域分布，但全局连接估计仍可能困难。热点城市分区远大于偏远区域时，统一阈值和维护周期不合适，可进一步拆分或使用不同资源策略。

空分区过多也会增加规划时间和目录负担。分区粒度应让每个分区足够大以摊薄管理成本，又足够小以支持裁剪、归档和恢复。

新记录必须可靠路由，超出已建范围时应明确失败或进入受监控默认分区。默认分区长期积累会隐藏配置遗漏。

附加已有表为新分区前，要验证约束和数据范围。在线迁移可分批复制、对账和切换，期间需控制双写或增量变化，不能只在最后比较总行数。

按时间分区便于将旧数据分离、压缩或归档。删除整个分区通常比逐行删除高效，但归档和恢复仍要保存元数据、权限和索引定义。

单机 PostgreSQL 分区仍共享实例资源和故障域。它不会自动提供跨节点扩展、地域容灾或独立容量。若目标是分布式存储，需要另外评估一致性、路由和运维模型。

分区也不能修复低效算法。查询需要全球聚合时仍要访问所有相关分区，过细分区甚至更慢。空间连接两侧采用不兼容分区方式时，数据重分布或大量组合仍不可避免。

有效分区应在目标查询上证明扫描分区数、读取量、延迟和维护改善，并持续观察数据倾斜。它是数据生命周期与查询计划的共同设计，不是一次建表选项。

分区键应来自稳定且高频的裁剪条件。若大多数查询按时间过滤，行政区分区未必有效；若业务总按租户或区域隔离，纯时间分区又可能扫描过多数据。可以通过查询日志统计过滤组合、返回比例和维护操作，再选择单维或组合策略。分区键一旦改变，数据迁移和索引重建成本通常较高，因此不应只依据一次慢查询决定。

跨界几何需要明确归属规则。按质心归属实现简单，但查询边界附近对象时必须扩大候选范围；复制到所有相交分区提高局部查询效率，却需要去重和同步更新。采用规则应写入数据契约，并用跨分区查询验证完整性。

分区数量还会影响规划时间、元数据和自动维护。应设置单分区目标规模与上限，监测数据倾斜，并保留合并冷分区或拆分热点分区的操作流程。

调整分区方案前应准备双写或受控停写窗口，并对迁移前后按空间范围和时间范围进行行数、面积及关键属性对账。回滚方案不仅要能恢复表定义，还要能识别迁移期间新增或修改的数据，避免旧分区恢复后丢失增量。