實現SQL Server 索引底層與操作中的注意事項
本文主要介紹的是SQL Server 索引底層的實現，以及對索引結構的具體描述，非聚集索引的描述，以及對非聚集索引在實際操作中要注意的相關事項的具體描述，以下就是文章的相關問題的描述。
頁和盤區（Page and Extents）
你的表（Tables）中數據實際上都存儲在頁（pages）里，除了BLOB類型的數據。如果某列的字段的類型為BLOB那么將有一個16字節的指針指向BLOB page。頁是MS SQL Server中數據存儲的最小單位。
每頁包含以行（row）為單位保存數據。一行只能存儲在一個頁中。每頁可以容納8KB的信息。因為這個原因，每行的***值為8KB。一組相鄰的8個頁被稱為一個盤區（Extent）
堆文件和分配映射索引（Heap and the Index Allocation Map(IAM)）
堆文件在sysindexs表中只有一行記錄，并且其indid = 0. sysindexs.FIRSTIAM字段指向了IAM頁鏈表中一個IAM頁，IAM頁是用來管理SQL Server已經給堆文件分配的空間。MS SQL Server2000用IAM（Index Allocation Map）頁來在堆文件中導航（navigate）。在堆文件中，數據頁（data page）和數據頁中數據沒有按照特定的順序存儲，也沒有鏈接在一起。數據頁之間唯一的邏輯鏈接是通過IAM頁中記錄來實現的。
索引結構（Index Structure）
所有的SQL Server 索引都是 B-Trees。在這種樹的頂端有一個根頁（root page），通過root page來訪問N個中級（intermediate level）頁，直到樹的底部、或葉級（leaf level）。可以通過樹中每個節點的指針從上向下掃描整個索引樹。另外，每個SQL Server 索引級（index leves）（可能是intermediate leve or leaf level）都有一個頁鏈（page chain）。
在一個索引中有許多intermediate level。索引樹的級數（樹的高度）與索引碼的寬度、索引類型、記錄行數和表中的頁數有關，并且索引樹的級數是影響索引性能的一個重要參數。
非聚集索引（Nonclustered Indexs）
一個非聚集索引與一本書的索引相似。數據存儲在一個地方，索引存儲在另外一個地方，可以通過索引中的指針來訪問存儲的數據。索引中的條目是按照索引碼的值按序存儲，但是表中的信息可以按照不同的順序存儲（如可以按照聚集索引存儲）。如果表中沒有創建聚集索引，那么表中的記錄就不能保證按照某種特定的順序。
與你用一本書的索引方式一樣，SQL Server2000也是先通過非聚集索引檢索到查找數據在表的位置，然后通過該位置來檢索數據。這使得非聚集索引非常適合精確匹配查詢（This makes nonclustered indexes the optimal choice for exact match queries）,因為索引條目中包含了你需要查找數據的位置信息。
如果當前的表是以聚集索引方式存儲，那么非聚集索引的位置信息就是聚集索引的索引碼（index key）；否則，位置信息就是row ID（RID)，每個RID由file number、page number和 slot number of row（每行記錄的槽號）。比如，要在一個表中檢索某個employee ID（emp_id），該表已經有在emp_id列上創建了非聚集SQL Server 索引，SQL Server查找索引樹，找到一個索引條目包含你需要查找的emp_id,然后利用其中RID來訪問到對應數據頁中的值。
注意事項
非聚集索引適用于以下場景：
列中包含大量的不同值，如last name 和 first name 構成的復合索引（假如已用另外列創建的聚集索引） 。如果某列中只有很少的不同值，如0或者1，大多數查詢不會利用該索引的，因為一個表掃描通常更有效率。
不返回大量結果集的查詢 Queries that not return large result sets
經常被包含在一個查詢條件語句（WHERE clause）的列,且該查詢返回精確配備（return exact matches）
決策支持系統中經常需要表之間的關聯（join）和聚集（group）。在被包含在join和grouping操作的列上建立非聚集索引，和在外鍵列上建立聚集索引。
一個給定的查詢包含了表中所有的列，這樣可以減少對表或聚集SQL Server 索引的訪問。（Covering all columns from one table in a given query. This eliminates accessing the table or clustered index altogether.）我的理解就是覆蓋索引。
聚集索引(Clustered Indexs)
一個聚集索引決定了一個表中數據的物理存儲順序。一個聚集索引與一個電話目錄相似，電話目錄是按照last name來存放。因為聚集索引決定一張表中數據的物理存放順序，所以一張表只能有個聚集索引,一個聚集索引可以包含多個列（復合索引），就像電話目錄一樣按照last name 和 first name記錄一樣，聚集索引與Oracle中的IOT'S(Index-Organized Tables)相似。
一個聚集索引對范圍查詢非常有效率efficient on columns that are often searched for ranges of values。當用聚集索引把***個行檢索出來之后，后續行一定能保證在物理上是相鄰的。例如，應用的某個查詢需要頻繁執行一個范圍查詢，聚集索引可以快速定位到滿足條件的***個數據，然后再檢索表中與之相鄰的記錄直到***一條記錄。
這樣可以調高這類查詢的性能。另外，如果某列經常用來對表中的數據進行排序（sort），該情況下也可利用聚集SQL Server 索引來節省每次排序的時間。
當索引值唯一時，需要查找一個指定行，此時聚集索引也是高效率的。例如，用最快的方式來找到一個指定empoyee ID的employee記錄就是在emp_id列上創建一個聚集索引。
注意事項
在創建聚集索引時，SQL Server 索引列應該盡量少，這一點很重要。如果定義一個大的索引碼，那么該表中的任何非聚集索引就會顯著的增大，因為每個非聚集索引葉級索引條目都包含了一個聚集索引碼。
聚集SQL Server 索引適用于以下場景：
列中包含大量的不同值
返回一個范圍記錄的查詢，像BETWEEN, >, >=, <, and <=.的操作；
順序訪問的列
返回大量記錄的查詢
在查詢中某列被頻繁的包含在join或group語句中，尤其該列也是該表的外鍵。在ORDER BY或 GROUP BY語句的列上建立聚集索引可以減少SQL Server對數據的排序，因為表中行已經是有序的了，這樣可提高查詢的性能。
在OLTP類的應用中經常需要快速查找某行記錄，尤其是一主鍵的來查找，此時可在主鍵上創建一個聚集索引。
聚集索引不適合以下場景：
頻繁變化的列。這樣造成了表中行經常移動，
寬鍵（wide keys）聚集索引的SQL Server 索引碼被所有的非聚集索引來用來檢索，所被存儲在每個非聚集索引的葉級索引條目中。
【編輯推薦】
