sql - 我对 "select distinct"的理解正确吗？

Question

我们最近发现我们的一个系统存在性能问题，我想我已经解决了，但我不确定我的理解是否正确。

以最简单的形式，我们有一张表 blah我们根据关键字段将各种值累积到其中。基本形式是:

recdate   date
rectime   time
system    varchar(20)
count     integer
accum1    integer
accum2    integer

有比这更多的累加器，但它们都是相同的形式。主键由 recdate组成, rectime和 system .

随着值被收集到表中，给定 recdate/rectime/system 的计数递增并将该键的值添加到累加器中。这意味着可以通过使用 accumN / count 获得平均值。 .

现在我们还有一个 View ，指定如下:

create view blah_v (
    recdate, rectime, system, count,
    accum1,
    accum2
) as select distinct
    recdate, rectime, system, count,
    value (case when count > 0 then accum1 / count end, 0),
    value (case when count > 0 then accum2 / count end, 0)
    from blah;

换句话说，该 View 为我们提供了累加器的平均值，而不是总和。它还确保在计数为零的情况下我们不会被零除(这些记录确实存在并且我们不允许删除它们所以不要费心告诉我它们是垃圾 - 你'重新向合唱团讲道)。

我们已经注意到执行以下操作之间的时间差:

select distinct recdate from XX

取决于我们是使用表格还是 View ，差异很大。我说的是表为 1 秒， View 为 27 秒(有 100K 行)的差异。

我们实际上将其追溯到 select distinct .似乎正在发生的是 DBMS 实际上正在加载所有行并对它们进行排序以删除重复项。这很公平，这就是我们愚蠢地告诉它要做的事情。

但是我很确定 View 包含主键的每个组件这一事实意味着无论如何都不可能有重复项。我们已经验证了这个问题，因为如果我们创建另一个没有不同的 View ，它的执行速度与基础表相同。

我只是想确认我的理解 select distinct如果包含所有主键组件，则不能有重复项。如果是这样，那么我们可以简单地适当更改 View 。

Answer 1

在这种情况下， DISTINCT 对您没有任何好处，因为由于基础表上的 PRIMARY KEY 约束，您的不同字段已经保证是唯一的。您可以尝试将 View 重写为:

create view blah_v ( 
    recdate, rectime, system, count, 
    accum1, 
    accum2 
) as select
       recdate, rectime, system, count, 
       case when count > 0 then accum1 / count else 0 end,
       case when count > 0 then accum2 / count else 0 end,
       from blah;

分享和享受。