Postgres中的索引扫描与顺序扫描答案

【问题标题】：Index Scan Vs Sequential scan in PostgresPostgres中的索引扫描与顺序扫描
【发布时间】：2021-06-23 12:02:59
【问题描述】：

我正在使用 Postgres 数据库，我试图在 1000000 行的表上查看索引扫描和顺序扫描之间的区别

描述表格

\d grades

然后解释分析 10 到 500000 之间的行

explain analyze select name from grades where pid between 10 and 500000 ;

然后解释分析 10 到 600000 之间的行

explain analyze select name from grades where pid between 10 and 600000 ;

对我来说奇怪的是为什么它在第一次查询和第二个中的顺序扫描，尽管它们按同一列查询它包含在索引中。

【问题讨论】：

标签： sql database postgresql indexing query-optimization

【解决方案1】：

这是因为如果 SELECT 返回表中所有行的大约 5-10% 以上，则顺序扫描比索引扫描快得多。并且您的第二个查询达到了该阈值；因为您正在获取更多行

【讨论】：

请@eshirvana 在第一次查询时从行中检索到大约 50% 而不是 10% 并向我解释索引扫描

【解决方案2】：

如果您只需要单个表行，则索引扫描比顺序扫描快得多。如果您需要整个表，顺序扫描比索引扫描快。
介于两者之间的是 PostgreSQL 在这两种访问方法之间切换的转折点。

您可以调整random_page_cost 以影响选择顺序扫描的点。如果您有 SSD 存储，则应将参数设置为 1.0 或 1.1，以告诉 PostgreSQL 索引扫描在您的硬件上更便宜。

【讨论】：

【解决方案3】：

PostgreSQL 使用基于成本的优化器，而不是基于规则的优化器。如果您采用索引扫描的估计成本 18693，并通过两个计划之间的预期行的比率线性扩展它（这不完全是计划器所做的，但应该是一个足够好的第一个近似值）你得到22330。这高于seq scan的预期成本21372，所以它选择seq scan。

如果你以同样的方式增加索引扫描的实际时间，你会得到 89 毫秒，这比 seq 扫描的实际速度略快。所以也许规划者在这里犯了一个非常轻微的错误，但在实践中肯定没有什么可担心的。

如果运行时间的差异是 10 倍，而不是 10%，那可能值得进一步研究。

【讨论】：