Sql Server 2005 统计信息用途
1, 什么是统计信息
以下是官方的对统计信息的描述：
按照默认设置，如果表中的某列没有索引，则SQL Server会自动为该列创建统计。然后，查询优化器评估该列中数据分布范围的统计信息，以选择一个更为有效的查询处理方案。分辨自动创建的统计很简单，在SQL Server 7.0和SQL Server 2000中，自动创建的统计的前缀为_WA_Sys。
个人感想：
以前对_WA_Sys开头的统计信息一直不知道有什么用，在学习了oracle时的CBO和三个算法（嵌套循环，合并连接和hash连接）才发现这个_WA_Sys开头的统计信息和索引的统计信息对我们用户没用，对数据库是很重要的。
2, 统计信息内容：
dbcc show_statistics('[[zping.com]]]',idx_operator)
运行上面命令以后，出来下列信息：
Name Updated Rows Rows Sampled Steps Density Average key length String Index
idx_operator 07 24 2008 8:15PM 721370 721370 200 0.002035875 63.99907 YES
这里的信息说明：
name:统计信息的名称。 Updated :上一次更新统计信息的日期和时间
Rows :表中的行数。 Rows Sampled :统计信息的抽样行数。
Steps:分发步骤数(在sql server最多200步） Average key length :所有索引列的平均长度
这些信息是对统计信息一个汇总
还有下列信息：
All density Average Le
相关文档：
如何让你的SQL运行得更快
---- 人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、 ......
今天做SQL 优化，查找执行计划时，执行计划，发现此执行计划与以往的计划有所区别；找录互联网，终于找一篇有关研究比较深入的文章；
原执行计划使用的是索引扫描，突然一下会使用索引覆盖技术，效率大增；
SELECT * 的真相：索引覆盖(index coverage)
SELECT *的效率很糟糕吗？当然，所有人都知道这一点，但是为什么 ......
上回我们说到评估一条语句执行效率主要看逻辑 IO （啥是逻辑 IO ，啥是物理 IO 见联机文档），这次我们继续。
我们先说说，返回多行结果时，为什么 SQLServer 有时会选择 index seek ，有时会选择 index scan 。
以 nonclustered index 为例说明。
像所有的索引 B 树一样，非聚集索引树也包括完全由索引数据组成的根� ......
在SQL Server 2008下，网上以前流行的截断日志并收缩文件的方法不适合了，报语法错误。
同时因为我的数据库日志增长非常快，大概每天在1G以上，因此必须对其进行收缩。
经过在系统上的测试，感觉用SQL SERVER的维护计划更可行，现将操作方式简介如下：
注：下面的说明中也提到了使用差异备份，因为数据库文件增长也非 ......
为什么需要数据压缩
首先可能需要讨论的问题就是为什么在存储成本不断降低的今天，微软还要煞费苦心地在SQL Server中实现并且不断改进数据压缩技术呢?
尽管存储成本已经不再是传统意义上的首要考虑因素，但是这并不代表数据库尺寸不是一个问题，因为数据库尺寸除了会影响到存储成本之外，还极大地关联到管理成本� ......
