SUM()比SQL中的SELECT()花费更少的时间.这个怎么运作？

Question

我有一个包含100万条记录的SQL表.我打电话的时候

SELECT *
   FROM [AdventureWorksDW2012].[dbo].[LotTable]

完成查询需要13秒.

我运行以下查询来获取ID列的SUM().它包含包含加号和减号的随机数.

 SELECT SUM(NewestID)
   FROM LotTable

这个查询花了500毫秒.要执行SUM(),SQL引擎应该读取值并对其应用一些操作.但它如何比SELECT()快速运行.背后的逻辑是什么？请参阅下面的图片.谢谢.

Answer 1

这是预期的行为.您会看到,当您向数据库系统发送查询时,会发生以下几种情况:

• 对查询进行分析,优化并设计执行模式,
• 执行查询(!),
• 结果传达给客户(!)

最后两项(带有感叹号)是加速的潜在来源.

首先,如果总结值,则不需要存储所有这些值.实际上,你使用累加器.因此,成熟的数据库系统将使用值初始化累加器,0然后对于它找到的每一行(匹配可选约束),它将该值添加到累加器.关键是,累加器使用固定数量的内存.例如,对于整数,通常小于10个字节.因此累加器存储在(快速)存储器中.

一个优点SUM(..)是它是关联的:((a+b)+c)+d等于(a+b)+(c+d).根据数据库的工作方式和配置方式,它可以在几个工作人员之间分配任务,每个工作人员计算一部分表的总和.然后将这些子项汇总在一起.

另一方面,如果执行SELECT查询,则会逐行写入结果.结果是线性内存使用:对于匹配的每一行,我们需要内存.对于大型表,旧行可能会被"交换"出CPU缓存,有时甚至是内存.因此执行查询需要更长的时间.

最后系统需要响应.现在,如果你执行一个SUM(..),那只是一行.因此传输的数据量很小.一个SELECT查询通常会转移数百行.当然,传输大量数据比花费少量数据需要更多时间.