为何DBeaver查询PostgreSQL数据极快？count(*)却耗时久？

你的判断没错，这些现象完全是PostgreSQL的特性导致的，和DBeaver无关，下面逐个拆解原因：

1. SELECT * FROM table_a; 快速返回的本质 #

你看到的200ms是DBeaver拿到第一批200行数据的时间，不是全表1.25亿行加载完成的时间。DBeaver默认使用PostgreSQL的游标（Cursor）机制，会把查询拆分成多次小批量请求（每次200行），数据库不需要一次性把全表数据都返回，只需要先返回第一批满足条件的行，后续你滚动界面时再继续拉取剩余数据。这是流式获取的优化，并非真的能在200ms内扫完1.25亿行。

2. SELECT count(*) FROM table_a; 耗时久的核心原因 #

PostgreSQL的count(*)必须逐行统计符合当前事务可见性规则的行数——因为MVCC（多版本并发控制）机制，每个事务能看到的行可能不同，数据库无法直接用系统元数据里的行数来快速返回结果。对于1.25亿行的表，全表扫描一遍统计行数需要23秒是完全正常的，哪怕给表加了普通索引，也无法直接用来快速计算count（除非是覆盖所有可见性判断的特殊索引，一般场景下不会这么做）。

3. 排序时性能差异的根源 #

• 按主键排序+LIMIT 200快：主键本身是唯一且有序的B-tree索引，PostgreSQL可以直接从主键索引的开头取前200条记录，再回表获取对应行的所有字段，这个过程几乎不需要额外计算，速度自然快。
• 按其他列排序+LIMIT 200慢：
  • 如果该列没有索引：PostgreSQL需要先全表扫描所有1.25亿行，把数据放到内存临时表或磁盘临时文件中完成排序，再取前200行，全表扫描+排序的成本极高。
  • 如果该列有索引：看起来慢的原因通常是优化器认为用索引回表的成本更高——索引只存该列和主键值，要获取*对应的所有字段，需要逐个通过主键回表查询数据。对于1.25亿行的表，哪怕只取200行，优化器可能判断全表扫描后排序的代价更低，因此选择了全表扫描的执行计划。你可以用EXPLAIN ANALYZE SELECT * FROM table_a ORDER BY other_col LIMIT 200;查看具体执行计划验证这一点。

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