11.11. 仅索引扫描 #
PostgreSQL 中的所有索引都是二级索引，也就是说，每个索引都与表的主数据区分开存储（在 PostgreSQL 术语中，这个主数据区称为表的堆）。这意味着，在普通索引扫描中，每次取回一行都需要同时从索引和堆中取数据。此外，尽管满足某个可索引 WHERE 条件的索引项通常在索引中彼此接近，但它们引用的表行却可能分布在堆中的任何位置。因此，索引扫描的堆访问部分会涉及大量对堆的随机访问，这可能很慢，尤其是在传统旋转介质上。（正如第 11.5 节中所述，位图扫描试图通过按排序顺序进行堆访问来缓解这项代价，但那也只能缓解到一定程度。）
为了解决这个性能问题，PostgreSQL 支持仅索引扫描，它可以仅凭索引而不访问堆来回答查询。基本思路是直接从每个索引项中返回值，而不是再去查对应的堆项。要使用这种方法，有两个根本限制：
索引类型必须支持仅索引扫描。B-树索引总是支持。GiST 和 SP-GiST 索引对某些操作符类支持仅索引扫描，但对另一些则不支持。其他索引类型则完全不支持。底层要求是，索引必须实际存储原始数据值，或者至少能够重建出每个索引项对应的原始数据值。反例是 GIN 索引，它不能支持仅索引扫描，因为每个索引项通常只保存原始数据值的一部分。
查询只能引用存储在索引中的列。例如，假设某个表的
x和y列上有一个索引，且该表还有一列z，那么下面这些查询可以使用仅索引扫描：SELECT x, y FROM tab WHERE x = 'key'; SELECT x FROM tab WHERE x = 'key' AND y < 42;
但下面这些查询则不能：
SELECT x, z FROM tab WHERE x = 'key'; SELECT x FROM tab WHERE x = 'key' AND z < 42;
（表达式索引和部分索引会让这条规则变得更复杂，下文会讨论。）
如果这两个基本要求满足，那么查询所需的所有数据值都能从索引中取得，因此从物理上说仅索引扫描是可行的。不过，在 PostgreSQL 中，任何表扫描还有一个额外要求：它必须验证每个取回的行对该查询的 MVCC 快照是否“可见”，如第 13 章所述。可见性信息并不保存在索引项中，而只保存在堆项中；因此乍看之下，似乎每次取回行无论如何都要访问堆。这在表行最近被修改过时的确如此。然而，对于很少变化的数据，这个问题有办法绕开。PostgreSQL 会跟踪表堆中每个页面是否其中所有行都已经足够老，以至于对当前和未来所有事务都可见。这个信息保存在该表的可见性映射中的一个位里。仅索引扫描在找到候选索引项后，会检查对应堆页面的可见性映射位。如果该位已设置，那么这行就已知可见，数据可以直接返回而无需进一步工作。如果没有设置，就必须访问堆项来判断该行是否可见，这样相对标准索引扫描就没有性能优势。即使在成功的情况下，这种做法也是用访问可见性映射来替代访问堆；但由于可见性映射比它描述的堆小四个数量级，访问它所需的物理 I/O 要少得多。在大多数场景下，可见性映射始终都会缓存于内存中。
简而言之，尽管满足那两个基本要求时就有可能使用仅索引扫描，但只有当表中相当一部分堆页的“全部可见”（all-visible）映射位已被设置时，它才会带来收益。不过，很多表都会有相当大一部分行长期不变，因此这种扫描方式在实践中非常有用。
为了有效利用仅索引扫描，可以创建这样的索引：只有前导列用于匹配 WHERE 子句，而后面的列保存查询需要返回的“负载”数据。例如，如果经常执行如下查询：
SELECT y FROM tab WHERE x = 'key';
加快此类查询的传统做法，是仅在以下列上创建索引：x。但是，在(x, y) 上创建索引，就可能通过仅索引扫描实现该查询。如前所述，这种索引会比仅在 x 上创建的索引更大，因而代价也更高，所以只有在已知表基本静态的情况下，这种做法才有吸引力。注意，索引必须声明在(x, y) 上，而不是(y, x) 上，因为对于大多数索引类型（尤其是 B-树），不约束索引前导列的搜索效率不高。
原则上，仅索引扫描也可以和表达式索引一起使用。例如，给定一个 f(x) 上的索引，其中 x 是表的一列，那么按理说应该可以把
SELECT f(x) FROM tab WHERE f(x) < 1;
执行成一次仅索引扫描；如果 f() 是一个计算代价很高的函数，这会非常有吸引力。不过，PostgreSQL 的规划器目前在这种情况上还不够聪明。它只会在查询所需的所有列都能从索引取得时，才认为查询可能通过仅索引扫描执行。在这个例子里，除了在 f(x) 这个上下文中，x 本身并不需要，但规划器意识不到这一点，因此得出无法做仅索引扫描的结论。如果仅索引扫描看起来足够值得，可以通过在(f(x), x) 上声明索引来绕过这一点。第二列实际上并不预期会被使用，加入它只是为了让规划器认为仅索引扫描是可行的。还有一个额外注意事项：如果目标是避免重新计算 f(x)，那么规划器不一定会把那些不在可索引 WHERE 子句中的 f(x) 用法与索引列匹配起来。对于上面展示的简单查询，它通常能做对，但对于涉及连接的查询则不能。未来版本的 PostgreSQL 可能会修复这些不足。
部分索引与仅索引扫描之间也有有趣的相互作用。考虑例 11.3 中展示的这个部分索引：
CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
WHERE success;原则上，我们可以在这个索引上做仅索引扫描，以满足如下查询：
SELECT target FROM tests WHERE subject = 'some-subject' AND success;
但这里有个问题：WHERE 子句引用了 success，而它并不能作为索引的结果列取得。尽管如此，仍然可能做仅索引扫描，因为执行计划在运行时不需要重新检查 WHERE 子句的这一部分：索引中找到的所有项都必然满足 success = true，因此计划里无需显式检查它。PostgreSQL 9.6 及更高版本能够识别这种情况，并允许生成仅索引扫描；更早的版本则不能。