SQL Server中关于基数估计计算预估行数的一些方法探讨(关于sql的问题)

编辑：rootadmin

推荐整理分享SQL Server中关于基数估计计算预估行数的一些方法探讨(关于sql的问题)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:在sql server中关于数据库的说法正确的是,关于sql的问题,关于sql server数据库服务器登录账户的说法错误的是,关于sql server常用的数据类型,以下,关于sql server中的存储过程,下列说法中正确的是( ),在sql server中关于数据库的说法正确的是,关于sql server常用的数据类型,以下,SQL server中关于实例的描述,内容如对您有帮助，希望把文章链接给更多的朋友！

关于SQL Server 中的基数估计，官方文档Optimizing Your Query Plans with the SQL Server Cardinality Estimator里有大量细节介绍，但是全部是英文，估计也没有几个人仔细阅读。那么SQL Server 中基数估计的预估行数到底是怎么计算的呢？有哪一些规律呢？我们下面通过一些例子来初略了解一下，下面测试案例仅供参考，如有不足或肤浅的地方，敬请指教！

下面实验测试的环境主要为SQL Server SP2 （Standard Edition (-bit)）具体版本号为.0..0 ，如有在其它版本测试，后面会做具体说明。如下所示，我们先创建一个测试表并插入一些测试数据后，方便后面的测试工作。

我们来看看这个表的统计信息以及直方图内容。

SQL Server中有两种谓词：过滤谓词和连接谓词。我们先来看看过滤谓词的基数估计（预估行数），测试过程，如果要保持测试的公正性或不被其他因素影响，你可以使用下面的DBCC命令来排除干扰，如下例子所示：

（注意，执行时请勾选包含实际执行计划按钮）如上所示，预估行数（Estimated Number of Rows）为,跟实际行数一致。当然你换其他值，例如，，，，其预估行数（Estimated Number of Rows）跟实际行数都是正确的（SQL SERVER 中测试结果也相同）。那么如果我换一个不存在的值呢？预估行数会是多少呢？

如上所示，预估行数（Estimated Number of Rows）为1. 你换其他任何不存在的值，预估行数（Estimated Number of Rows）都为1。这个跟沿用了老的基数评估：超出统计信息范围，那么老的基数评估就认为不存在，评估行数为1。很显然，对于没有超出统计信息范畴的，但是确实不存在的记录，其预估行数（Estimated Number of Rows）也是1，这个基数估计确实是合理，也是正确的。那么如果我使用变量呢？这个预估行数（Estimated Number of Rows）又会是什么值呢？

如上截图所示，实际执行计划的预估行数（Estimated Number of Rows）是，那么如何计算来的呢？其实你可以根据公式来计算，如果不相信，你可以构造各种案例测试验证一下就能得到答案了.

[Row Sampled ]* [ALL density ] = * 0.2 = 也就是统计信息中抽样总行数*All Density（统计信息对象中各列的每个前缀的密度）

如果你加上OPTION(RECOMPILE)，那么预估行数（Estimated Number of Rows）又会变成1

如果你赋予@SID值为，并加上OPTION(RECOMPILE)时，那么预估行数（Estimated Number of Rows）就会变成EQ_ROWS的值了

接下来，我们修改一下SQL语句，将查询条件从等于符号改为大于符号，如下所示：

如上所示，预估行数（Estimated Number of Rows）变为了，那么这个值是怎么计算得来的呢？

计算公式是： [Row Sampled ] * 0.3（%）

*0.3=

肯定会有人问，你怎么知道是 [Row Sampled ] * 0.3 呢？不会是你逆推的吧。不错，这里是一个推测（网上也有不少资料都确认是0.3，权且当做计算公式中的一个常量），而且也做了不少测试，确实就是%。例如你将@SID赋值为，预估行数（Estimated Number of Rows）依然为，如果你怀疑是缓存的执行计划缘故，你可以先清空缓存的执行计划，结果依然如此。根据我的测试，不管你给@SID赋予任何值，预估行数（Estimated Number of Rows）全部为

如果SQL加上 OPTION(RECOMPILE) ，然后@SID赋予RANGE_HI_KEY里的值，那么预估行数（Estimated Number of Rows）又是如何计算的呢？

这个是这样计算的，如下所示，大于的RANGE_HI_KEY有，，，他们对应的EQ_ROWS值相加 + + =，不信你可以测试一下，将@SID赋予，那么预估行数（Estimated Number of Rows）就会变成.

那么我们再修改一下SQL查询语句，例如，我们要做一个区间查询，预估行数（Estimated Number of Rows）又会有什么变化呢？

如上所示，预估行数（Estimated Number of Rows）为. 这个值怎么来的呢？其实它是这样计算的:

那么如果我在SQL Server 中执行该SQL语句或者使用查询跟踪标记来关闭新的基数评估，数据库优化器使用老的基数评估，你会发现预估行数（Estimated Number of Rows）为了。如下所示：

这里的计算公式是

那么现在我们往表TEST_ESTIMATED_ROW里面插入条记录，此时这个数据量是不会触发统计信息更新的，而此时ID=的值超出了直方图中的RANG_HI_KY的最大值，也就是说直方图中没有统计这些新插入的数据，那这种情形称作升序键问题（ascending key problem）。在更统计信息新前就对这些数据运行查询，就会发生此类问题。

那么再来看看下面SQL的预估行数（Estimated Number of Rows），如下所示：

那么预估行数（Estimated Number of Rows）为. 是怎么计算来的呢？其实这个问题就是 Your Query Plans with the SQL Server Cardinality Estimator里面介绍，这种是基数估计的计算公式为 [All density] * [Rows Sampled] 。但是实际测试发现这个例子并不是如此，那么我们先来亲自测试一下白皮书文档里面的例子（注意，数据库实例是SQL Server ，AdventureWorks的兼容级别为）,看看文档里面的例子是否正确。

可以看到OrderDate的统计信息为_WA_Sys__4BFF

SQL Server中关于基数估计计算预估行数的一些方法探讨(关于sql的问题)

DBCC SHOW_STATISTICS('Sales.SalesOrderHeader', _WA_Sys__4BFF);

从上可以看到最后统计信息更新时，采集的RANGE_HI_KEY的最大值为-- ::，那么我们插入条记录，此时这个数据量并不会触发统计信息更新。

然后我们开启SQL跟踪标志,你会发现下面SQL的预估行数为1。因为此时优化器采用老的基数估计。

取消SQL跟踪标志时，数据库使用新的基数估计时，预估函数变为了.

白皮书里的例子确实是如此，但是最上面那个例子，不清楚预估行数是如何计算的，尽管做了一些推测，但是在其它例子中始终不能验证。不知是这个白皮书有误还是SQL Server的基数估计做了调整，还是说基数估计（CE)的算法远远不止这么简单？我在这个问题上纠结了两天，依然没有搞清楚！在测试、推测过程中，我发现一个新的问题：当表里面新增了数据，那么之前的测试列子结果是否还是一样呢？答案是不一样了。如下所示：

预估函数从变为了.，这个是怎么计算来的呢？个人推测是这样得来的（如下所示）。

也就是说升序键问题（ascending key problem）也会影响预估函数。上面都是简单SQL的预估行数（Estimated Number of Rows）的推演、实际情况中，SQL要比这个复杂得多，那么在复杂情况下，例如多个过滤谓词的情况下，基数估计又是怎样预估行数的呢？由于前面例子构造的比较简单，不适合后面的演示，那么我们就用Optimizing Your Query Plans with the SQL Server Cardinality Estimator里的例子来简单演示一下：

如下所示，过滤谓词[StateProvinceID]、[City]、 [PostalCode]对应的统计信息分别为IX_Address_StateProvinceID、_WA_Sys__B1、_WA_Sys__B1。

从SQL Server 7 ~ SQL Server ，如果查询条件中，两个或多个谓词使用AND联结，那么各个谓词的选择率Si的乘积将作为查询预估函数的选择率

其计算结果为0. ，它低于1行。所以查询优化器使用估计的最小行数 (1)。下面看看SQL Server 中新的基数估计是如何计算预估行数的。

那么新的基数估计（SQL Server ）的预估行数（Estimated Number of Rows）.是怎么计算来的呢？其实它们是选择率使用下面这样一个公式，其中p0 < p1 < p2 < p3 < p4

计算结果为. ~= . 是否还是有一些差别呢？你使用下面SQL对比，就会发现，其实原因是小数点后精确位数和四舍五入导致的。具体我也不知道计算估计精确位数。

那么OR Selectivity又是如何计算的，我们先来看看老的基数估计是是如何计算的，如下例子所示：

计算公式：(S1 + S2) ? (S1 * S2) ，那么(S1 + S2) ? (S1 * S2) 计算的值为

然后和AND操作，我们执行SQL Server 以前的AND的选择性是这样计算的S1 * S2

最后的计算结果如下：

那么我们再来看看SQL Server 下OR Selectivity的计算公式

那么这个预估行数（Estimated Number of Rows）是怎么算出来的呢？ Paul White 的博客介绍，是通过下面这样计算来的。

A OR B = NOT （( NOT A) AND (NOT B)) 就是说A OR B 和 NOT （( NOT A) AND (NOT B)) 是等价的。