【问题标题】:Index scan backward vs index scan向后索引扫描与索引扫描
【发布时间】:2011-06-28 09:19:36
【问题描述】:

在对具有非常高 I/O 等待的服务器进行故障排除时,我注意到有很多 I/O 来自执行 SELECT max(x) FROM t WHERE y = ? 的查询。

我的索引是btree (x, y)

我注意到查询计划执行 Index Scan Backward 以获得最大值。那不好吗?我是否应该担心这一点并可能添加另一个索引(反向)?或者有没有更好的方法来创建适合此类查询的索引?

【问题讨论】:

    标签: postgresql query-optimization


    【解决方案1】:

    对索引进行排序,最低值在前。要找到最大值,向后索引扫描会首先找到最大值:)。

    我假设 SELECT min(x) 会导致正常的索引扫描,是吗?

    【讨论】:

    • 是的,min(x) 进行正常扫描。
    【解决方案2】:

    不,这还不错,从第一个索引页开始所需的时间与从最后一个索引页开始所需的时间相同。使用DESC 创建降序索引时,您可以看到“差异”。

    索引 (y,x) 可能更适合此查询。

    【讨论】:

    • 在 (y, x) 上创建索引将查询成本从 10k 降低到 300,并大大缩短了查询时间。拥有 x DESC 没有任何区别。感谢您的提示!
    • 太棒了,谢谢先生!在改变索引后,我遇到了类似的问题和类似的性能影响。
    • stackoverflow.com/users/271959/frank-heikens 你能详细说明为什么 (y, x) 上的索引比 (x, y) 上的索引具有更短的查询时间。谢谢。
    • @nisanth074 我相信这完全取决于 WHERE 方面的索引选择性。在大多数情况下,您首先要过滤掉例如300 行,其中y = ? 然后选择max(x)。如果您在(x,y) 上有索引,则无法过滤y 值。您可以只过滤xxy,而不是单独过滤y。研究复合索引顺序偏好。我认为它比我更能解释它。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-06-23
    • 2019-08-26
    • 1970-01-01
    • 2012-01-31
    • 2021-08-12
    • 1970-01-01
    相关资源
    最近更新 更多