《MicrosoftSqlserver2008Internals》读书笔记--第六章Indexes:I

《Microsoft Sql server 2008 Internals》索引目录： 《Microsoft Sql server 2008 Internals》读书笔记--目录索引 在第五章主要学习了table的内部存储结构，第七章《Special storage》中将继续深入学习存储机制，那将是本书最难理解的一章。第六章主要介绍in

《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?

select * from sys.dm_db_index_physical_stats(DB_ID('testdb'),null,null,null,null);[python] view plaincopyprint?

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