《Microsoft Sql server 2008 Internals》读书笔记--第六章Indexes:Internals and Management(1)

《Microsoft Sql server 2008 Internals》索引文件夹：

《Microsoft Sql server 2008 Internals》读书笔记--文件夹索引

在第五章主要学习了table的内部存储结构，第七章《Special storage》中将继续深入学习存储机制，那将是本书最难理解的一章。

第六章主要介绍index的基础知识，第八章是《query Optimizer》,以下我们先来看看第六章：Indexes:Internals and Management。这一章分为三部分：

1、介绍Index的使用、概念和内部构造,你也将了解索引怎样被存储和它们是怎样被检索的。

2、深入了解数据被改动时内部存储发生了什么，是怎样发生的。以及SQL Server怎样确保一致性(consistence)。

你还将了解到改动数据的索引（对性能的）的潜在影响，比方整理。

3、索引的管理和维护。

前言：索引的优点是不言而喻的。

一个良好的索引可能将你的查询请求从数百万的I/O下降到few甚至更少。

相同。一个过度的索引设计(over-indexing)比起不用索引可能后果更为严重。

因此。掌握必要的索引物理存储及存储引擎、策略、优化知识对于一个SQL设计人员是至关重要的。

首先，我们来一起学习第一部分：

索引分为聚集索引 (clustered index)和非聚集索引(nonclustered index)两种，在聚集索引的表中。表数据是依照聚集键排序被逻辑存放的。当你找到你要的数据时。搜索同一时候完毕。而非聚集索引的表中。

索引结构是全然和数据自身分离的。当你開始查找索引的时候，你必须依照某些引用指针(Reference Pointer)的排序得到实际的数据。

关于怎样创建索引(index)，请查阅MSDN:

http://msdn.microsoft.com/zh-cn/library/ms188783.aspx

◆SQL Server Index B-Tree

在SQL Server中。索引被依照B-Tree结构组织，B-Tree即(balanced-tree),SQL Server使用一种特殊的B+tree结构。不像通常的树，B-Tree总是倒的(inverted)，它的根root(单个page)在顶部,叶(Leaf)在底部。

中间级别的level取决于多种因素。B-Tree是一个在不同场合被重载(overload)的词,在本书中。它意味着整个的索引结构，例如以下图所看到的：

重要的是，我们须要理解SQL　Server中B-Tree是怎样被构建的(constructed)。以及每个Level中包括什么。我们通过一些简单的概念入手。

首先。索引有两个非常主要的组件：一个叶级(leaf level)，一个或多个非叶级(non-leaf levels)。后者主要用于叶级的导航。此外，第一个中间级(first intermediate level)也被用于整理分析和在大序列索引查询的驱动预读(read-ahead)。

非页级(non-leaf Level)的存在主要是为了在叶级帮助迅速导航到一行的架构。而不是直接到数据本身。

每一个非页级存储了自下而上在每一页(page),直到Root级被创建。越高的级（即距离leaf越远的）存放更少的信息, 由于每一个处于该级的行仅仅包括位于下一级的最小键值。加一个指针。实际上。这些key（最多900字节或16个列）在SQL　Server中有助于保持索引树相对的小。

以下我们使用一个包括1,000,000（即1百万）“行”的索引的叶级为例。

首先我们得明白，不管是leaf leave还是non-leaf level都是被存储在SQL Server pages(8KB pages)中。在这个样例中，non-leaf“‘ 行”将有4000字节。也就是说，每页仅仅能存储两行。

对于一个百万“行”的表而言。我们的索引的叶级将有500,000页。相对而言。这是一个非常宽的行结构，然而。我们并没有浪费非常大的空间。假如我们叶级页有两个3,000字节的行，我们仍然每页两“行”，于是我们将浪费2,000字节的空间。

注意，这里为什么用"行"而不用数据行(Data Rows)。这是由于：这个页级可能是聚集索引（这自然就等于数据行）。也可能这些叶级行是一些非聚集索引的包括性非键值列被加到索引的叶级中的行。当包括性列被使用时，叶级页能够包括更宽的行（超过900字节或16列限制）。

在本例中，索引创建时页级将是4GB大小，(500,000个8kb大小的page)。假设使用最大限制，那么最后长到Root的树将会更小，而且最多有8个级，例如以下：

■ Root page of non-leaf level(Level 7)=2 rows=1 page(8 rows per page)

■ Intermediate page of non-leaf level(Level 6)=16 rows=2 page(8 rows per page)

■ Intermediate  non-leaf level(Level 5)=123 rows=16 page(8 rows per page)

■ Intermediate  non-leaf level(Level 4)=977 rows=123 page(8 rows per page)

■ Intermediate  non-leaf level(Level 3)=7,813 rows=977 page(8 rows per page)

■ Intermediate non-leaf level(Level 2)=6,2500 rows=7,813 page(8 rows per page)

■ Intermediate  non-leaf level(Level 1)=50,000 rows=6,2500 page(8 rows per page)

■ Leaf  level(Level 0)=1,000,000 rows=500,000 page(8 rows per page)

更小的键大小将会有更快的级别。以相同数据为例，假设有更小的索引键将在非叶级带来更小的行大小，因此能够存储很多其它的行。

假设仅仅有20字节，将能够每而存储404行数据：

■ Root page of non-leaf level(Level 3)=4 rows=1 page(404 rows per page)

■ Intermediate non-leaf level(Level 2)=1,238 rows=4 page(404 rows per page)

■ Intermediate  non-leaf level(Level 1)=50,000 rows=1,238 page(404 rows per page)

■ Leaf  level(Level 0)=1,000,000 rows=500,000 page(2 rows per page)

请记住：更窄而不是更宽的键(key)将给索引带来更好的效率。

最重要的是：索引的大小（即级的数量）取决于三点：1、索引定义。2、基表(table)是否有一个聚集索引。

3、索引叶级的page数量。当中，叶级页的数量直接表中行大小和行数量。这并非说在索引中一定要使用窄索引。

有时还要适当使用宽索引。

此外，像"包括性列"和filtered indexes也会影响索引的大小和用途。当然，最重要的是，使用正确的索引。不是吗？

分析索引的工具(Tools for Analyzing Indexes)

一、使用sys.dm_db_index_physical_stats

[python] view
plaincopyprint?

1. select * from sys.dm_db_index_physical_stats(DB_ID('testdb'),null,null,null,null);

关于sys.dm_db_index_physical_stats的很多其它使用，请參看MSDN：

http://msdn.microsoft.com/zh-cn/library/ms188917.aspx

二、使用DBCC IND命令,这是一个MSDN未公开的命令。

[python] view
plaincopyprint?

1. exec ('DBCC IND(testdb,[dbo.Fixed],-1)')

下一节将继续学习物理索引结构(physical Index Structure)。

邀月注：本文版权由邀月和CSDN共同全部。转载请注明出处。

助人等于自助!   [e-mail]

转自：http://blog.csdn.net/downmoon/article/details/5280152