41

查询基本上是:

SELECT DISTINCT "my_table"."foo" from "my_table" WHERE...

假装我 100% 确定DISTINCT查询的部分是它运行缓慢的原因,我省略了查询的其余部分以避免混淆,因为我主要关心的是不同部分的缓慢(不同的是总是缓慢的根源)。

有问题的表有 250 万行数据。此处未列出的目的DISTINCT 必需的(因为我不想返回修改后的查询,而只是有关使不同查询在DBMS级别运行得更快的一般信息,如果可能的话)。

如何在DISTINCT不更改 SQL 的情况下更快地运行(特别是使用 Postgres 9)(即,我无法更改传入的 SQL,但可以访问在数据库级别优化某些内容)?

4

3 回答 3

48

distinct通常,您可以通过使用 agroup by代替来使此类查询运行得更快:

select my_table.foo 
from my_table 
where [whatever where conditions you want]
group by foo;
于 2011-07-06T15:25:53.930 回答
29

您的 DISTINCT 导致它对输出行进行排序以查找重复项。如果您在查询选择的列上放置索引,数据库可能能够按索引顺序读取它们并保存排序步骤。很大程度上取决于查询的细节和所涉及的表——你说你“知道问题出在 DISTINCT”确实限制了可用答案的范围。

于 2011-07-06T15:29:04.453 回答
7

您可以尝试增加 work_mem 设置,具体取决于您的数据集的大小它可能导致将查询计划切换到散列聚合,这通常更快。

但在全局设置太高之前,请先阅读它。您可以轻松炸毁您的服务器,因为该max_connections设置充当该数字的乘数。

这意味着如果你要设置work_mem = 128MB并且你设置max_connections = 100(默认),你应该有超过 12.8GB 的​​ RAM。您实际上是在告诉服务器它可以使用那么多来执行查询(甚至不考虑 Postgres 或其他方式使用的任何其他内存)。

于 2011-07-08T00:40:23.817 回答