《Microsoft Sql server 2008 Internals》读书笔记--第八章The Query Optimizer(5)

??????峤

　　读书笔记订阅地址：
　　http://blog.csdn.net/downmoon/category/647266.aspx/rss
　　《Microsoft Sql server 2008 Internals》索引目录：
　　《MicrosoftSql server 2008 Internals》读书笔记--目录索引
　　上篇主要列举了统计的概念和统计的设计、统计的浓度。本文将关注筛选统计和字符串统计、基准估计。
　　■筛选统计
　　作为SQL Server 2008中新增的筛选索引的一部分，筛选统计功能被加入。这意味着（某个基于筛选谓词的表的行的子集的）统计对象被创建。可以通过sys.stats视图来查看无数据输出。筛选统计可以避免一个常见的问题：即由于数据列与列之间的相关性而变得倾斜。比如，我们有一个表cars,一列Make,一列 Model。如下记录：
　　Create table Cars(Car_ID int ,Make nvarchar(20),MODEL Nvarchar(20));truncate table carsinsert into Carsselect 1,'Ford','F-150'union all select 2,'Ford','Taurus'union all select 3,'BMW','M3'
假定您想执行如下查询：
select * from cars where Make='Ford' and MODEL='F-150'
　　查询处理器试图作选择时，它假定每一个AND子句的条件是相互独立的，实际上执行的结果是各条件的乘积，即(1/3)*(2/3)=2/9。然而真实的结果应该是1/3,因为F-150 肯定是Ford。当数据量很大时，这个误差是惊人的。
　　筛选统计通过捕捉一个带条件的可能性从Model列进行筛选，筛选条件为 Make列为Ford,这在大多数情况下会修正统计中的运算错误，特别是在where 子句包含一个相对较小的惟一值时非常有效。
　　除了假定独立性外，查询优化器还采用其他假定来简化估算进程。另外两个假定是统一性假定和包含性假定。没有这些假定，许多常见的查询将会变得性能寒碜。
　　■字符串统计
　　SQL Server 2005采取了一项新内容来改善针对字符串的基准估计，叫做字符串统计或Trie Trees，SQL Server直方图的上限是200阶（或200个惟一值），来存放整个表的分发信息。特别在查询中使用like时，两百个惟一值不足以提供（针对字符串的）精准的标量评估，而在表外存储大量的字符串会占用大量的空间。Trie Tree此时可以用来在列中高效地存储一些样例字符串。
　　Trie Trees没有公开，但它通常的结构类似于如下：
如果一个列包含如下值：
ABC
　　AAA
　　ABCDEF
　　ADAD
　　BBB
对应的tier Tree如下：

　　SQL Server实际上在列中存储了一个字符串的样例。这提供了一种存储远超过200的惟一子字符串的频度信息的能力。
　　■基线估计细节
　　在优化期间，查询里的每一个运算符被计算以评估该操作影响的行数，这有助于查询优化器基于不同的查询计划作出正确的权衡。这个过程是自下而上的。基表基准和统计被用于输入到其上的树节点。我们看一个例子：
　　Create table Table2010_3(col1 int,col2 int,col3 int);goset nocount onBEGIN TransAction;Declare @i intset @i=0while @i<10000BEGINInsert into Table2010_3(col1,col2,col3) values(@i,@i,@i%50);set @i=@i+1ENDCommit TransactiongoCreate statistics s2010_3 on Table2010_3(col3);goselect col1,col2 from Table2010_3 where col3<10
　　其逻辑查询树如下：

对于该查询，Filter操作请求在每一个参与谓词的列（本例中是col3）上进行统计，该请求被传承到Table2010_3,适当的统计对象被创建或更新的地方。统计对象此时被传递到筛选器，以决定操作的选择性。选择性被用于从样例延展评估。
　　一旦一个操作的可选择性被计算，它与当前查询的当前行数相乘。
　　看下图：

　　因为0-49中有10个是小于10的，即10/50＝0.2
　　10000*0.2=2000 行。
　　我们来验证一下，

　　本例中，存储在直方图中的浓度信息为0.02
　　又如下列查询： select COUNT(*) from Table2010_3 group by col3

　　评估的行数为(1/0.02)*(10000/10000)=50
　　当一个多列统计对象被创建时，它按照统计对象的顺序为这些被计算的列集计算浓度信息。我们再看下例：
Create table Table2010_4(col1 int,col2 int,col3 int);goset nocount onBEGIN TransAction;Declare @i intset @i=0while @i<10000BEGINInsert into Table2010_4(col1,col2,col3) values(@i%5,@i%10,@i%50);set @i=@i+1ENDCommit Transactiongo
　　如果前两个列是随机数，则 浓度信息可能类似下图：

　　这解释了每个col1,col2,col3的组合实际上是惟一的。通过检查进入基准估计进程的各种各样的输入(Input)，判断计划在编译期间有无使用合理的信息成为可能。
　　本文主要介绍了筛选统计和字符串统计、基准估计，下文将关注Limitation和Costing
邀月注：本文版权由邀月和CSDN共同所有，转载请注明出处。
助人等于自助! 3w@live.cn