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