为何PostgreSQL执行ANALYZE语句时显示行数比表实际行数多？

我正在统计PostgreSQL表中所有记录的数量：

groups=# select count(*) from auth_user;
 count
---------
 1000000
(1 row)

该表的结构如下：

groups=# \d auth_user;
Table "public.auth_user"
 Column      | Type                     | Modifiers
--------------+--------------------------+--------------------------------------------------------
 id           | integer                  | not null default nextval('auth_user_id_seq'::regclass)
 password     | character varying(128)   | not null
 last_login   | timestamp with time zone | 
-- 剩余结构省略

但执行ANALYZE语句后，显示的行数比上述实际统计的行数多，请问这是什么原因？

这是PostgreSQL里非常常见的统计信息偏差问题，我来给你拆解几个最可能的原因：

• 统计信息是抽样估算值
  PostgreSQL的ANALYZE命令并不会精确遍历整个表计数，它会随机抽取表中的部分数据块，基于抽样结果估算总行数和其他统计指标。对于100万行的大表来说，抽样误差完全可能导致估算值和count(*)的精确结果出现差异——尤其是如果抽样样本刚好覆盖了数据分布不均匀的区域时，偏差会更明显。

• 并发数据变动的影响
  如果你执行select count(*)和ANALYZE的时间点之间，有其他会话在对auth_user表进行插入、删除或更新操作，那么ANALYZE看到的数据状态和你之前计数时的状态已经不一样了。count(*)是获取执行瞬间的精确快照，而ANALYZE是另一个时间点的抽样统计，时间差带来的数据变化自然会导致行数不一致。

• 未清理的死元组干扰
  PostgreSQL的MVCC多版本并发控制机制会保留旧版本的行记录（也就是“死元组”），这些死元组在被VACUUM清理之前仍然存在于磁盘上。ANALYZE在抽样时会把这些未被清理的死元组也算入统计，而count(*)只会统计当前事务可见的活行。如果你的表近期有大量删除/更新操作且没及时做VACUUM，就会出现ANALYZE统计的行数比count(*)多的情况。

• 统计信息未及时更新
  虽然你执行了ANALYZE，但如果表在ANALYZE执行过程中仍有大量数据变动，或者自动ANALYZE的阈值设置导致统计信息没有完全更新，也可能出现偏差。不过这种情况相对少见，通常手动执行ANALYZE后统计信息会很快同步。

验证与解决方法 #

你可以通过以下步骤确认原因并修正：

1. 查看当前表的活行和死行统计：

   SELECT n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'auth_user';
   

   如果n_dead_tup数值较大，说明死元组是主要原因。
2. 执行VACUUM ANALYZE auth_user;，先清理死元组再重新生成统计信息，之后再查看统计数据，应该会和count(*)的结果更接近。

内容的提问来源于stack exchange，提问作者Mangu Singh Rajpurohit