对于SQL Server数据库来说，性能一直是一个绕不开的话题。而当我们去分析和研究性能问题时，执行计划又是一个我们一直关注的重点之一。
我们知道，在进行编译时，SQL Server会根据当前的数据库里的统计信息，在一定的时间内，结合本机资源，挑选一个当前最佳的执行计划去执行该语句。
那么数据库分析引擎如何使用这些统计信息的呢？数据库引擎会根据数据库里的统计信息，去计算每次操作大约返回多少行。这个动作称之为基数计算（cardinality estimation）。数据库分析引擎会基于这些信息判断选择逻辑或物理的操作符，操作成本等等，生成一系列执行计划并最终挑选一个合适的执行计划。
在SQL Server 2014中，基数计算与之前的版本相比出现了较大的变化，并且这些变化对执行计划的生成有客观的促进作用。新的基数计算相对于之前的版本而言并不是增加了一个新的补丁，修复了一些bug，可以说是一次重写，甚至基于的数学计算模型也发生了变化。
新的基数计算主要适用于DW(数据仓库)的场景，会给DW系统带来较大的性能提升。
就效果而言，由于采用的数学模型的一些变化，新的基数计算在对返回行数预估上，较以往往往会更加准确。
以下两个例子是对新旧基数计算的对比。
1. 独立性假设
测试语句如下：
1 Select * 2 From Cars 3 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有以下特点：
- 它适用于分区表，并且主要的数据更新发生在新的分区
- 每个分区都有自己的统计信息对象，全局会将这些统计更新合并
- 由于多数数据改变发生的新的分区，因此更新统计信息时，我们只需要更新新区的统计更新，系统会将其在与其他的分区的统计信息更新。这样会避免去重建其他分区的统计信息。
- 分析引擎使用全局统计信息而不是每个分区的统计信息。
- 当自动统计信息打开后，对每个分区而言，触发的阈值为该分区20%的数据更新。对全局而言是平均分区大小的20%。