我有一张大桌子，可以定期运行类似select date_att> date'2001-01-01'的查询。我试图通过将表聚集在date_att上来提高这些查询的速度，但是当我通过explain analysis运行那些查询时，它仍然选择顺序扫描表，即使在像date_att> date的SELECT date_att这样简单的查询上也是如此。 '2001-01-01'。为什么会这样呢？我知道，由于查询返回了表的很大一部分，优化器将忽略索引，但是由于表是由该属性聚集的，因此它不应该能够真正快速地对表进行二进制搜索到日期所在的位置>“ 2001-01-01”，然后返回所有结果？与不进行群集查询相比，此查询仍需要花费大量时间。
似乎您在混淆两个概念：
表的PostgreSQL集群
根据PostgreSQL中的索引对表进行集群，可将表行（存储在堆表中）的顺序与集群时索引的顺序对齐。从文档：
集群是一项一次性操作：表在随后进行更新时，更改不会集群。http://www.postgresql.org/docs/9.3/static/sql-cluster.html
聚簇有可能（通常）提高范围查询的查询速度，因为选定的行通过巧合存储在堆表的附近。没有什么可以保证此订单！因此，优化器无法假定它是正确的。
例如，如果插入满足where子句的新行，则该行可能会插入表中的任何位置，例如，存储1990年的行的位置。因此，这种假设不成立：
但是由于表是由该属性聚类的，所以它不应该能够真正快速地二进制>搜索表到date>'2001-01-01'并在此之后返回所有结果的点吗？
这将我们带到您提到的另一个概念：
聚集索引
这是完全不同的东西，PostgreSQL完全不支持，但是许多其他数据库（SQL Server，带有InnoDB的MySQL以及Oracle在这里称为“索引组织表”）也完全不支持。
在这种情况下，表数据本身存储在索引结构中-没有单独的堆结构！由于它是一个索引，因此每个insert/ update/的顺序也都保持不变delete。因此，您的假设将成立，实际上，我希望上述数据库的行为与您期望的一样（假定该date列是聚簇键！）。
希望能澄清这一点。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句