PostgreSQL 9.6中B-tree索引扫描为何返回全量行？

这确实是个值得深究的问题，我来帮你梳理几个可能的原因，以及对应的排查方向：

1. 统计信息过时或不准确 #

PostgreSQL的查询优化器完全依赖统计信息来评估不同执行计划的成本。如果你的bookings表最近有大量的数据插入、更新或删除，但没有及时更新统计信息，优化器可能无法判断可以通过B-tree索引的最右节点快速获取最大值，反而认为全索引扫描是更稳妥的选择。

你可以先执行这条命令更新统计信息：

ANALYZE bookings;

之后再用EXPLAIN ANALYZE SELECT max(total_amount) FROM bookings;查看执行计划是否有变化。

2. 索引可见性映射（Visibility Map）未标记足够的可见页面 #

PostgreSQL的B-tree索引虽然逻辑上是有序的，但索引条目对应的表行可能处于不可见状态（比如被删除但还没被VACUUM清理，或者被未提交的事务隐藏）。如果表的可见性映射（VM）没有标记大部分页面为"全部可见"，优化器会认为直接取索引最右节点的行可能是不可见的，为了确保拿到真正的最大值，它会选择扫描整个索引来逐一验证行的可见性。

你可以通过这条查询查看表的可见性情况：

SELECT relname, relpages, relallvisible 
FROM pg_class 
WHERE relname = 'bookings';

如果relallvisible的值远小于relpages，说明大部分页面的可见性不确定，这时候可以尝试执行VACUUM ANALYZE bookings;来清理无效行并更新可见性映射，之后再观察执行计划。

3. PostgreSQL 9.6的优化器局限性 #

对比后续版本（比如PostgreSQL 10及以上），9.6的查询优化器在处理B-tree索引的极值查询（max/min）时，逻辑可能不够完善。尤其是对于numeric这种可变长度的数值类型，9.6的优化器可能没有触发直接跳转至B-tree最右叶子节点的优化逻辑，而是默认选择全索引扫描。

如果上述两种方法都没有改善，可能需要考虑升级到更高版本的PostgreSQL，或者接受在9.6中这种场景下的索引扫描行为——不过全索引扫描通常比全表扫描还是要快一些的，毕竟索引的数据量比表小。

内容的提问来源于stack exchange，提问作者Александр