我对"选择明显"的理解是否正确？

Question

我们最近发现了我们的一个系统的性能问题,我认为我有修复,但我不确定我的理解是否正确.

在最简单的形式中,我们有一个表blah,我们根据关键字段累积各种值.基本形式是:

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

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

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

现在我们还有一个关于该表的视图,如下所示:

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;

换句话说,视图给出了累加器的平均值而不是总和.它还确保我们在计数为零的情况下不会得到除零(这些记录确实存在,我们不允许删除它们所以不要打扰告诉我它们是垃圾 - 你'重新讲道合唱团).

我们注意到之间的时差:

select distinct recdate from XX

根据我们使用表格还是视图而变化很大.我说的是表的差异为1秒,视图的差异为27秒(100K行).

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

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

我只是想确认一下,select distinct如果它包含所有主键组件,就不能有重复项.如果是这样,那么我们可以简单地适当地改变视图.

Answer 1

distinct是的，当所有主要关键元素都包含在内时，询问结果是没有意义的。

表的主键约束已经排除了这些列之间的重复，但 DBMS 仍将处理元组以确保它们是不同的。