SQLServer索引创建策略——第1部分：离线、连续、非分区
SQLServer索引创建策略——第1部分：离线、连续、非分区--王成辉翻译整理，转贴请注明出自微软BI开拓者www.windbi.com
--原帖地址
创建器(写数据到要建的索引里) | 排序(根据索引键排序) | 扫描(从源里读取数据)为了为索引创建二叉树，我们不得不从源里先排序数据。先是扫描源，然后排序（如可能－在内存中进行[注]），然后从排序里创建二叉树。为什么需要在创建二叉树前先排序呢？理论上不必排序，使用正常的DML直接把数据插入要建的索引里（没有排序），但这样做是随机插入的，在二叉树里随机插入要求先为正确的页节点搜索二叉树，然后再插入数据。尽管搜索一个二叉树相当快，但在每次插入之前这样做就远远没有达到最佳了。所以对于索引创建操作来说，为新的索引使用排序顺序来排序数据，这样在向要建的索引里插入数据时就不是随机的插入了，实际上它是一个追加操作，这就是为什么比随机插入快的原因。当在排序和索引创建器之间插入数据的时候，所有的记录一复制完就释放排序表的每一个扩展盘区。这样整个磁盘空间消耗量就从可能的索引大小的3倍（源大小+排序表大小+二叉树大小）减少到仅仅索引大小的2.2倍（近似）。[注]不能保证在内存中排序；决定是否在内存中排序取决于可用的内存和实际的记录量。在内存中排序自然是很快的（这时磁盘空间需求量也将更少，因为不必在磁盘上为排序表分配空间），但不是必需的。虽然性能比内存中排序慢些，但总是把数据存放到磁盘上。对于一个索引创建操作，缺省地使用用户数据库（创建索引的那个数据库）来存放排序数据，但如果用户指定了SORT_IN_TEMPDB，那么将使用tempdb来存放。每一个排序表至少要求40个页面去运行（3200KB）（即使只有很少的数据去排序）（以后我们将看看并行情况下同时有几个排序表的情形）。当为排序计算所需内存时，为了在内存中排序而试图分配足够的内存。对于大索引创建操作来说把整个排序数据存放到内存中是不可能的。如果没有为索引创建操作提供至少40个页面，那么创建索引将失败。索引创建的最后总是创建完整的统计。好的统计信息有助于查询优化器产生更好的计划，用户可以使用Create或Update统计命令来强迫SQLServer产生或刷新某个特定对象上的统计。当创建一个新的索引时，既然要涉及到每一行，那就趁此机会创建一个完整的统计，同时造福以后。结论:为了创建一个连续的离线的非分区的索引，需要大约索引大小的2.2倍的自由磁盘空间和为了查询执行器能启动处理过程所需的至少40个页面大小的可用内存。上一篇：SQLServer索引创建策略——引言（II）下一篇：SQLServer索引创建策略——第2部分：离线、并行、非分区
拓狼 最后编辑于 2007-05-25 13:48:28
虽有智慧,不如乘势;虽有鎡基,不如待时。
君子学以聚之,问以辨之,宽以居之,仁以行之。
独学而无友，则孤陋而寡闻。
