修改一行SQL代码 机能晋升了100倍

这次查询共耗费22s，我们可以通过下图对这22s举办很直观的相识，个中大部门时刻耗费在Postgres和OS之间，而磁盘I/O则耗费很是少的时刻。

在最低程度，这些查询看起来就像是这些CPU操作率的峰值。在这里首要是想证实一个要害点：数据库不会守候磁盘去读取数据，而是做排序、散列和行较量这些事。

通过Postgres获取与峰值最靠近的行数。

显然，我们的查询在大大都环境下都井井有条的执行着。

Postgres的机能题目：位图堆扫描

rows_fetched怀抱与下面的部门打算是同等的： 

Postgres行使位图堆扫描（ Bitmap Heap Scan）来读取C表数据。当要害字的数目较少时，它可以在内存中很是高效地行使索引构建位图。假如位图太大，查询优化器会改变其查找数据的方法。在我们这个案例中，必要搜查大量的要害字，以是它行使了很是相似的要领来搜查候选行而且单独搜查与x_key和tag相匹配的每一行。而全部的这些“在内存中加载”和“搜查每一行”都必要耗费大量的时刻。

荣幸的是，我们的表有30%都是装载在RAM中，以是在从磁盘上搜查行的时辰，它不会示意的太糟糕。但在机能上，它如故存在很是明明的影响。查询过于简朴，这是一个很是简朴的key查找，以是没有显而易见的数据库或应用重构，它很难找到一些简朴的方法来办理这个题目。最后，我们行使 PGSQL-Performance邮件向社区告急。

办理方案

开源帮了我们，履历富厚的且代码孝顺量很是多的Tom Lane让我们试试这个：

你能发明有啥差异之处吗？把ARRAY换成了VALUES。

我们行使ARRAY[...]罗列出全部的要害字来举办查询，但却诱骗了查询优化器。Values(...)让优化器充实行使要害字索引。仅仅是一行代码的改变，而且没有发生任何语义的改变。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!