# 11.12.检查索引使用情况
尽管PostgreSQL中的索引不需要维护或调整,但检查实际查询工作负载实际使用了哪些索引仍然很重要。检查单个查询的索引使用情况是通过解释命令其在这方面的应用如所示第14.1节。还可以收集有关正在运行的服务器中索引使用情况的总体统计信息,如中所述第28.2节.
很难制定一个确定创建哪些索引的通用程序。在前几节的示例中已经展示了一些典型案例。大量的实验往往是必要的。本节的其余部分给出了一些提示:
总是跑分析第一此命令收集有关表中值分布的统计信息。需要这些信息来估计查询返回的行数,规划人员需要这些信息来为每个可能的查询计划分配实际成本。在没有任何实际统计数据的情况下,会假定一些默认值,这几乎肯定是不准确的。在没有运行的情况下检查应用程序的索引使用情况
分析
因此,这是一个失败的事业。看见第25.1.3节和第25.1.6节了解更多信息。使用真实数据进行实验。使用测试数据设置索引将告诉您测试数据需要哪些索引,但仅此而已。
使用非常小的测试数据集尤其致命。虽然从100000行中选择1000行可能是索引的候选,但从100行中选择1行很难,因为这100行可能适合一个磁盘页,而且没有比顺序获取1个磁盘页更好的计划。
在编写测试数据时也要小心,当应用程序尚未投入生产时,这通常是不可避免的。非常相似、完全随机或按排序顺序插入的值会使统计数据偏离真实数据的分布。
当不使用索引时,强制使用索引对测试非常有用。有一些运行时参数可以关闭各种计划类型(请参见第20.7.1节).例如,关闭顺序扫描(
启用顺序扫描
)和嵌套循环联接(启用嵌套循环
),这是最基本的计划,将迫使系统使用不同的计划。如果系统仍然选择顺序扫描或嵌套循环联接,那么不使用索引可能有更根本的原因;例如,查询条件与索引不匹配。(什么样的查询可以使用什么样的索引在前面的章节中进行了解释。)如果强制使用索引确实使用了索引,那么有两种可能性:要么系统是正确的,使用索引确实不合适,要么查询计划的成本估算没有反映现实。因此,您应该在有索引和无索引的情况下对查询计时。这个
解释分析
命令在这里很有用。如果成本估算结果是错误的,那么同样有两种可能性。总成本通过每个计划节点的每行成本乘以计划节点的选择性估计来计算。可以通过运行时参数(如中所述)调整计划节点的估计成本第20.7.2节).不准确的选择性估计是由于统计数据不足。可以通过调整统计数据收集参数来改善这一点(请参见改变桌子).
如果不能成功地将成本调整到更合适的程度,那么可能必须明确地强制使用索引。您可能还想联系PostgreSQL开发人员来检查这个问题。