PostgreSQL大表高效并行读取的实现方案探讨

1. 用OFFSET/LIMIT模拟分页并行读取是否可行？ #

这种方式完全不推荐，核心问题有两个：

• 性能极低：OFFSET值越大，PostgreSQL需要先扫描并跳过的行数就越多，TB级大表下，高OFFSET的查询会把大量时间浪费在无效扫描上，多线程同时执行这类查询会严重消耗数据库的CPU和IO资源。
• 数据一致性无法保证：如果扫描期间表有写入、更新或删除操作，不同线程的查询会基于不同的数据快照，很容易出现行重复读取或者遗漏的情况——比如某行在第一个线程扫描完成后被删除，第二个线程的OFFSET会因此偏移，导致原本属于第二批次的行被跳过。

2. 是否更适合采用PostgreSQL原生分区表？ #

是的，原生分区表是这类场景的最优选择，理由如下：

• 并行效率极高：每个分区都是独立的物理表，应用的每个线程可以单独扫描一个分区，不需要跳过任何数据，能充分发挥数据库和应用的多核CPU性能，扫描效率比OFFSET/LIMIT方式高几个量级。
• 避免数据不一致：只要分区键设计合理，每个分区的数据范围清晰明确，并行扫描时不会出现行重复或遗漏的问题。
• 维护成本低：PostgreSQL原生分区表支持自动分区、分区修剪等特性，后续的维护操作（比如归档旧分区）也更便捷。

3. 扫描期间表有变更，如何通过事务保证多SELECT的一致视图？ #

PostgreSQL的MVCC（多版本并发控制）机制可以完美解决这个问题：

• 将所有并行的SELECT查询放在同一个REPEATABLE READ隔离级别的事务中（或者让所有线程共享同一个事务快照）。事务启动时会生成一个数据库快照，事务内的所有查询都会基于这个快照返回数据，完全不受事务启动后的写入、更新、删除操作影响，确保所有线程读到的是同一时间点的一致表视图。
• 你可以这样设置事务：

BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- 各线程的SELECT查询基于该事务执行
COMMIT;

注意：PostgreSQL默认的READ COMMITTED隔离级别下，每个查询会生成新的快照，无法保证跨查询的一致性，必须显式设置为REPEATABLE READ。

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