当PostgreSQL单表数据量达到千万级甚至亿级时，即使索引设计合理，查询延迟也会明显上升。原因是B+树索引层级增加，每次查询需要更多磁盘IO，同时写入操作可能触发页分裂和锁竞争。此时仅靠调整SQL或增加缓存已经难以从根本上解决问题，分库分表成为扩展数据库能力的必经之路。

分库分表并不是简单的把大表拆成小表，它涉及拆分维度选择、跨分片查询处理、全局ID生成、分布式事务等一整套工程问题。本文会围绕PostgreSQL慢查询场景，梳理从评估到落地的完整路径，帮助读者建立可执行的拆分方案。

一、什么时候需要分库分表：先做量化评估

拆分数据库是一个高成本动作，直接增加开发、运维和故障排查的复杂度。判断是否需要分库分表，应该基于量化指标而不是主观感受。常见触发条件包括：单表数据量超过一千万行且无法通过归档或分区表缓解；单库写入TPS接近磁盘或CPU瓶颈；慢查询中大量涉及跨页扫描；连接数频繁打满导致应用排队。

在正式拆分前，可以先尝试PostgreSQL原生的声明式分区表。声明式分区在PG 10之后支持良好，将大表按范围或列表拆成多个物理子表，但对外仍是一个逻辑表。对于只做单机扩展、数据量在数亿行以内的场景，原生分区往往能大幅降低索引高度，配合分区裁剪可以让查询只扫描少数分区。真正需要分库分表的是单机资源已经无法承载、需要把数据分散到多台机器的情况。

拆分维度上，垂直拆分按业务模块将不同表放到不同库，例如用户库、订单库、商品库。水平拆分则把同一张表按某个字段拆到多个库或多张表。拆分键的选择直接决定跨分片查询的比例，应该优先选择查询条件中出现频率最高、区分度足够的字段，比如用户ID、订单ID。避免使用性别、状态这类低区分度字段。

二、PostgreSQL分库分表的实现方案对比

PostgreSQL生态中实现分库分表有三类主流方案：原生分区表、Citus扩展、ShardingSphere中间件。原生分区表部署简单，不需要额外组件，但只能在一台机器内做水平拆分，无法突破单机存储和算力上限。它适合作为过渡方案，或者配合逻辑复制做读写分离。

Citus是PostgreSQL的分布式扩展，安装后可以把普通PostgreSQL变成分布式数据库。它通过协调节点和多个工作节点实现水平扩展，支持分布式表、参考表和本地表。Citus的优势是兼容PostgreSQL协议，应用基本无感知，而且分布式查询由扩展内部优化，支持跨分片聚合、分布式JOIN。它的不足是需要单独部署和管理工作节点，另外企业版功能更多，社区版有一些限制。

ShardingSphere属于中间件方案，应用连接ShardingSphere代理或使用JDBC驱动，由中间件完成SQL解析、路由和结果归并。这种方案对数据库本身无侵入，支持多种数据库，配置灵活。但中间件层会引入网络延迟，复杂SQL的解析和跨分片归并也可能成为新的瓶颈。对比来看，如果团队以PostgreSQL为主且希望快速扩展，Citus更轻量；如果存在多数据库混合或需要更细粒度策略，ShardingSphere更合适。

-- PostgreSQL原生声明式分区表示例
CREATE TABLE orders (
    order_id bigint NOT NULL,
    user_id bigint NOT NULL,
    amount numeric(12,2),
    created_at date NOT NULL
) PARTITION BY RANGE (created_at);
CREATE TABLE orders_2024 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
CREATE TABLE orders_2025 PARTITION OF orders
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

-- Citus创建分布式表示例
SELECT create_distributed_table('orders', 'user_id');
-- 此后orders表会按user_id哈希分布到多个工作节点

三、分库分表后的慢查询优化重点

拆分之后，单表数据量下降，单分片查询通常会变快，但跨分片查询可能比原来更慢。优化重点要转向分布式场景下的特殊问题。

全局唯一ID是最先要解决的。PostgreSQL自增序列在多个分片上会冲突，不能直接使用。常见做法是使用雪花算法生成64位长整型，包含时间戳、机器标识和序列号，既保证全局唯一又大致有序。也可以使用号段模式，由统一发号服务批量分配ID区间，各分片在区间内自增。雪花算法生成的ID时间有序，有利于按时间范围查询时减少跨分片扫描。

跨分片分页是另一个高频问题。传统的LIMIT OFFSET在分片环境下需要在每个分片取前N条再归并，偏移量越大性能越差。推荐改为基于游标的分页：客户端记录上一页最后一条记录的时间戳和ID，下一页用WHERE条件过滤，这样每个分片只返回符合条件的数据。对于需要精确总页数的场景，可以维护一个轻量级计数表，避免每次都跨分片COUNT。

聚合查询如SUM、COUNT、AVG，中间件会下推到各分片计算，再在协调层合并。对于COUNT可以分别COUNT后求和；对于AVG不能直接求平均值，需要SUM和COUNT分别汇总后相除。开发时需要了解这些归并规则，避免写出结果错误的SQL。

四、分库分表落地中的常见问题与规避策略

分布式事务是分库分表后最大的坑。跨分片更新无法依赖数据库本地事务保证原子性，强一致事务需要引入两阶段提交或Seata等方案，但会严重降低吞吐。实际业务中应尽量避免跨分片事务，把关联操作设计到同一个分片内，例如订单表和订单明细表都用订单ID作为拆分键，保证同一订单的数据位于同一分片。对于必须跨分片的场景，采用本地消息表或事务消息实现最终一致性。

扩容与数据迁移同样需要提前规划。采用一致性哈希可以在扩容时只迁移少量数据，但实现复杂；简单取模方式扩容需要全量重新分布。更稳妥的做法是预留足够多的分片数，例如一开始就拆成64个逻辑分片，物理上先部署在少数机器，后续扩容时迁移部分分片到新机器，逻辑分片编号不变，应用路由无需修改。

运维层面，分库分表后备份、监控、DDL变更都要考虑多实例。备份需要保证各分片时间点一致，可以使用PostgreSQL的逻辑复制或备份工具配合时间点恢复。监控要关注每个分片的数据量和慢查询，避免出现热点分片。DDL变更需要工具批量执行，并且尽量在线操作。最后要避免过度拆分：单分片保持几百万到几千万行的规模比较合适，分片数量过多会放大连接管理和查询归并的开销。