Compartilhar via


SQL 2014新功能介绍系列7 –针对基数估计的新设计(New Design for Cardinality Estimation)

对于SQL Server数据库来说,性能一直是一个绕不开的话题。而当我们去分析和研究性能问题时,执行计划又是一个我们一直关注的重点之一。

我们知道,在进行编译时,SQL Server会根据当前的数据库里的统计信息,在一定的时间内,结合本机资源,挑选一个当前最佳的执行计划去执行该语句。

那么数据库分析引擎如何使用这些统计信息的呢?数据库引擎会根据数据库里的统计信息,去计算每次操作大约返回多少行。这个动作称之为基数计算(cardinality estimation)。数据库分析引擎会基于这些信息判断选择逻辑或物理的操作符,操作成本等等,生成一系列执行计划并最终挑选一个合适的执行计划。

在SQL Server 2014中,基数计算与之前的版本相比出现了较大的变化,并且这些变化对执行计划的生成有客观的促进作用。新的基数计算相对于之前的版本而言并不是增加了一个新的补丁,修复了一些bug,可以说是一次重写,甚至基于的数学计算模型也发生了变化。

新的基数计算主要适用于DW(数据仓库)的场景,会给DW系统带来较大的性能提升。

就效果而言,由于采用的数学模型的一些变化,新的基数计算在对返回行数预估上,较以往往往会更加准确。

以下两个例子是对新旧基数计算的对比。

1. 独立性假设

测试语句如下:

Select *

From Cars

Where Make=‘Honda’ AND Model =‘Civic’

在测试数据库中运行上述语句,其中表的行数是1000行,Make=’Honda’ 有200行,Model=’Civic’ 有50行。

在之前般的CE中,会认为这两个筛选条件之前没关系,所以预测返回行数是0.05 * 0.2 * 1000 = 10, 而在新的版本CE中,会认为这两者之间应该是有关系的,因此会采用指数退避算法,预测返回值是0.05 * sqrt(0.2) * 1000 = 22.36。

实际返回行数50行。

因此新的CE会更加的保守,在这种情况下会更加准确。

 

2. 连接(join)的变化

当出现等值连接时,会采用下面的计算方法:

  • 选取两个输入中distinct值较少的一个
  • 上面步骤取得的值乘以两边的平均频率、

例如


 

新的基数计算涉及的修改较多,例如还有针对ascending key场景所做的修改,使用统计信息方法的修改等等。但是对传统的一些内容仍然保持原样,例如表变量预估为一行,存储过程中的本地变量会认为是未知值,parameter sniffing 问题仍然可能发生等等。

但是总整体而言,新的基数计算给DW场景的工作负载会带来客观的性能提升,包括编译时间和执行时间两方面。

前述中我们提到了统计信息,在SQL Server 2014中,会有一个新的统计信息概念,增量统计信息(Incremental Statistics)。

一般说来,统计信息记录的是列或者索引中的数据分布,数据密度等等。当用户打开自动统计信息更新后,假如数据发生了大约20%的变化,那么会触发统计信息自动更新。

在旧的版本数据库中,关于统计信息会遇有以下两个不足之处:1. 对于非常大的表,20%的自动统计信息阈值太大。2. 重建统计信息需要重新扫描或者重新取样扫描整个表,假如能做到只扫描新的数据,那么更佳。

以此为目标,SQL Server 2014 出现了一个新的功能增量统计信息(Incremental Statistics)。

Incremental Statistics有以下特点:

  1. 它适用于分区表,并且主要的数据更新发生在新的分区
  2. 每个分区都有自己的统计信息对象,全局会将这些统计更新合并
  3. 由于多数数据改变发生的新的分区,因此更新统计信息时,我们只需要更新新区的统计更新,系统会将其在与其他的分区的统计信息更新。这样会避免去重建其他分区的统计信息。
  4. 分析引擎使用全局统计信息而不是每个分区的统计信息。
  5. 当自动统计信息打开后,对每个分区而言,触发的阈值为该分区20%的数据更新。对全局而言是平均分区大小的20%。

这就是今天的分享,更多SQL 2014新功能介绍请持续关注本博客。 下周我们将会介绍可更新的列存储索引 (Updateable Column Store Indexes)。

Comments

  • Anonymous
    January 06, 2015
    新的CE对很多负载类型来说有提升,我最喜欢的就是自增键统计信息能估算出值了,否则估算为0经常会引起很多问题。