【问题标题】:Postgresql index and seq scanPostgresql 索引和序列扫描
【发布时间】:2021-11-03 02:28:51
【问题描述】:

我意识到一件有趣的事情。我有一个具有多列索引的表。

CREATE INDEX transaction_idx ON transaction USING btree (period_id, day_id, value_type, indicator_id);

当我像这样运行查询时:

select *
from transaction
where  period_id = '202104'
and day_id = 30
and  value_type = 1
and indicator_id = 2

DB 将进行 seq 扫描。

但如果我只是将 day_id 值更改为 20,那么 DB 将进行索引扫描。 去索引扫描

进行序列扫描 如果有人可以与我分享这件事的根本原因,我将不胜感激。

谢谢!

【问题讨论】:

  • 你能展示一下你的表结构(CREATE TABLE transaction ...),尤其是day_id列的数据类型吗?
  • 嗨@Edouard H。感谢您的评论,我刚刚解决了这个问题并分享我的解决方案。

标签: postgresql indexing


【解决方案1】:

好的,我已经更新了 random_page_cost 值,查询按我的预期运行。

alter database db set random_page_cost=0.7;

【讨论】:

  • 该解决方案可能是错误的,因为随机 I/O 不会比顺序 I/O 便宜。它可能会破坏其他查询的执行计划。也许您的统计信息已关闭,或者其他参数设置错误。使用您显示的模糊截断图像而不是格式化文本很难看到。
  • 嗨 Laurenz,感谢您的回复并分享您的关注。我想更清楚地解释它。我们使用的是 SSD 磁盘,I/O 性能优于 HDD。并且同一数据库中的最小表大小约为 2000 万条记录,并且每天不断增加 200k。这就是我们希望所有查询都应该进行索引扫描而不是序列扫描的原因
  • 我明白了。这是一个危险的交易 - 有时顺序扫描是最有效的策略。
  • 嗨 Laurenz,如果您不介意,可以与我们分享一些 postgresql 查询优化吗?我们什么时候应该使用 seq 扫描,应该设置什么正确的 random_page_cost 数字?比如 seq 扫描适用于小表,索引扫描适用于大表。
  • 我在第一条评论中分享了一些想法。是的,对于小表,顺序扫描是正确的。此外,如果您有一个仅过滤掉几行的WHERE 子句。
猜你喜欢
  • 2021-03-19
  • 1970-01-01
  • 2011-07-09
  • 1970-01-01
  • 2020-09-06
  • 2019-08-26
  • 2021-08-12
  • 2011-06-28
相关资源
最近更新 更多