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 要少很多。在大部分情况下，可见性映射总是会被保留在内存中的缓冲中。
总之，虽然当两个根本要求满足时可以使用只用索引的扫描，但是只有该表的堆页面中有很大一部分的“所有都可见”映射位被设置时这种索引才有优势。不过，有很大一部分行不被更改的表是很常见的，这也让这一类扫描在实际中非常有用。
为了有效地使用只用索引的扫描，可以选择创建时只让前导列来匹配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 和以后的版本将会识别这种情况，并且允许生成只用索引的扫描，但是旧版本无法这样做。