尽管在 PostgreSQL 里的索引并不须要维护和调节, 可是检查一下哪些索引是在实际查询工做中获得使用的仍然是很是重要的。 检查索引的使用是经过 EXPLAIN 命令进行的; 为此目的作的应用在 Section 13.1 里演示。 咱们也能够在一个运行的服务器上收集有关索引使用的所有可能性, 就想在 Section 24.2 里描述的那样。php
概括一个判断须要设置哪些索引的通用过程是很难的。 在前面的章节中已经列出了许多典型的例子。 在大多数状况下咱们都须要许多试验。本节的剩余部分就是给出一些这方面的窍门。html
老是先运行 ANALYZE。 这条命令收集关于表中数值分布的统计。猜想一个查询返回的行数须要这个信息, 而规划器须要这个行数以便给每一个可能的查询规划赋予真实开销值。 若是缺少任何真实的统计信息,那么就会假设一些缺省数值, 那确定是不许确的。所以,若是尚未运行 ANALYZE 就检查一个应用的索引使用情况,那实际上就是一次失败的检查。sql
使用真实的数据作实验。用测试数据设置索引将告诉你在测试数据中须要什么索引,而不是在全部数据中。服务器
最要命的是用很小的数据集。若是从 100000 行中选 1000 行是使用索引的好时机, 那么从 100 行中选 1 行很难说也须要索引, 由于 100 行极可能是装在一个磁盘页里面的, 所以没有任何查询规划能比经过顺序访问抓取一个磁盘页面更有效。oop
作测试数据的时候也要当心 -- 若是应用还不能在生产环境中使用, 那么这也是不可避免的。那些很是类似的数据,彻底随机的数据, 或者按照排序顺序插入的数据会令统计信息偏离实际数据应该具备的特征。测试
若是索引没有获得使用,那么在测试中强制它的使用也许有些价值。 有一些运行时参数能够关闭各类各样的查询规划(在 Section 17.6.1 中描述)。 好比,关闭顺序扫描(enable_seqscan)和嵌套循环链接(enable_nestloop)将强迫系统使用不一样的规划。 (这些规划是最基本的规划。)若是系统仍然选择顺序扫描或者嵌套循环联接, 那么在为什么索引没有获得使用的问题中可能有更基本的问题, 好比,查询条件和索引不匹配等。(咱们在前面的章节中介绍了什么样的查询可使用什么样的索引。)spa
若是强制索引用法的确使用了索引,那么就有两种可能∶ 要么是系统选择是正确的∶使用索引实际上并不合适, 要么是查询计划的开销计算并不反映现实状况。 这样你就应该对使用和不使用索引的查询进行计时。这个时候 EXPLAIN ANALYZE 命令就颇有用了。orm
若是实际状况说明开销计算是错误的,那么仍然有两种可能。 总开销是从每行的每一个规划节点乘以每一个规划节点的选择性估计的开销计算出来的。 规划节点的开销能够用一些运行时参数进行调节(在 Section 17.6.2 中描述)。 不许确的选择性估计是由于统计信息不够充分。 咱们能够经过调节统计收集参数(参阅 ALTER TABLE)提升选择性估计的精确度。htm
若是你没能经过将开销调整得更准确实现索引的使用,那么你可能不得不 求助于明确地强制索引使用。并且也许与 PostgreSQL 开发人员联系而且讨论你的状况也是值得考虑的。排序