SQL Distinct关键字会降低性能?

时间:2011-03-17 15:29:51

标签: sql plsql

我收到了一个使用distinct关键字的SQL查询。当我尝试运行查询时,至少需要一分钟时间才能连接两个包含数十万条记录的表并实际返回一些内容。

然后我取出了它,它在0.2秒内回来了。 distinct关键字真的会让事情变得那么糟糕吗?

编辑:这是查询


SELECT Distinct
c.username, o.orderno, o.totalcredits, o.totalrefunds,
o.recstatus, o.reason 

from management.contacts c 
join management.orders o
on (c.custID = o.custID)
where o.recDate > to_date('2010-01-01', 'YYYY/MM/DD')

4 个答案:

答案 0 :(得分:6)

是的,因为使用DISTINCT会(有时根据评论)导致结果被命令。排序数百条记录需要时间。

尝试GROUP BY所有列,有时可以让查询优化器选择更有效的算法(至少在Oracle中我注意到了显着的性能提升)。

答案 1 :(得分:3)

Distinct总是给我敲响警钟 - 它通常表示一个糟糕的桌面设计或一个不确定自己的开发人员。它用于删除重复的行,但如果连接正确,则很少需要它。是的,使用它需要很高的成本。

订单表的主键是什么?假设它是orderno那么那应该足以保证没有重复。如果它是其他的东西,那么你可能需要对查询做更多的事情,但是你应该把它作为删除这些区别的目标! ; - )

你还提到在检查行数时运行需要一段时间的查询 - 通常可以更快地将整个查询包装在“select count(*)from()”中,特别是如果你得到的话返回了大量的行。就在你明显测试的时候。 ; - )

最后,确保您已在订单表上索引了custID(也可能是recDate)。

答案 2 :(得分:2)

DISTINCT的目的是修剪所有选定列的结果集中的重复记录。

  • 如果任何选定的列在加入后是唯一的,您可以删除DISTINCT。
  • 如果您不知道,但是您知道所选列的值的组合是唯一的,则可以删除DISTINCT。

实际上,通常情况下,通过设计合理的数据库,您很少需要DISTINCT,在这种情况下,您可以(?)显然需要它。然而,RDBMS不能让它成为偶然,必须实际建立一个索引结构来建立它。

当人们不确定表格之间的JOIN和关系时,通常会发现DISTINCT到处都是。

此外,在谈论纯关系数据库的课程中,结果应该是一个合适的集合(没有重复元素=记录),你会发现人们为了理论上的正确性而坚持使用DISTINCT以保证这个属性是很常见的。 。有时这会蔓延到生产系统中。

答案 3 :(得分:0)

你可以试着像这样建立一个小组:

  SELECT c.username, 
         o.orderno, 
         o.totalcredits, 
         o.totalrefunds,
         o.recstatus, 
         o.reason
    FROM management.contacts c,
         management.orders o
   WHERE c.custID = o.custID
     AND o.recDate > to_date('2010-01-01', 'YYYY-MM-DD')
GROUP BY c.username, 
         o.orderno, 
         o.totalcredits, 
         o.totalrefunds,
         o.recstatus, 
         o.reason 

同时验证您是否在 o.recDate

上有索引