SQL Server 數據庫的整理優化的基本過程（二）
高建剛
第二節 索引
索引相信大家都不陌生，而且在因特網上，有了很多關於如何通過索引來優化數據庫的文章，在這裏，我主要是結合我的使用情況向大家推薦關於索引如何來提高和改善數據庫性能的。
衆所周知，在數據庫的數據存儲方面，數據是以分頁的形式存儲的，在數據量較小的時候，如果我們不建立索引，那麼整體的性能可能不會受到多大影響，但是如果數據量較大，達到千萬、甚至過億，如果仍然不採用索引，數據庫的檢索仍然會去遍歷所有的頁去找找你想要的那一點點數據，就會感覺到簡單的查詢效率很低，客戶抱怨，前端的程序開發人員也對數據庫性能不滿意，因此使用索引來提高性能這時候就顯得特別重要了。
在 SQL Server 中索引的存放是以平衡樹 Balance-Tree(B-Tree) 結構順序存放的，在有效的利用索引時，系統會根據建立的索引樹，通過二分查找方式查找符合條件的記錄，同時建立索引後，索引所佔用的硬盤空間也會比每條數據記錄的硬盤空間小一些，所以說無論是查找方式和讀取硬盤的空間都可以達到提高性能和查詢效率的目的。索引的理解，好比一本書的目錄，讀者可以通過目錄去快速找到自己想看的章節，而目錄在整本書的佔用書本頁數少，結構簡單，索引也是同樣的道理，這樣可能理解起來就比較容易接受了。
在 SQL Server 中，索引的結構包含三方面，根節點分頁 (Root Level) ，即索引結構的開始。子葉層 (Leaf Level) ，索引的最下層。非子葉層 (Non-Leaf Level) ，介於子葉層和根節點之間的結構。
SQL Server 的索引分爲聚集索引和非聚集索引兩類 ( 後續內容會單獨介紹全文檢索和全文索引 ) 。聚集索引每個表只能存在一個，它的建立標誌着數據表本身就是索引的一部分，因爲指定了聚集索引後，整個表的數據存儲都會按照用戶建立的聚集索引來擺放，在 SQL Server2000 以後的版本中，聚集索引已經可以指定由大到小還是由小到大的順序了 ( 還有分區、在線等其他特性，在此不累述 ) 。索引建立後會生成索引結構，也就是索引的根節點和非子葉層級，從而完成整個聚集索引的整體結構。數據表的數據的存放只能有一種原則，所以每個表的索引也就只能有一個聚集索引了。所以選擇一個表的字段作爲聚集索引時，要慎重。
那麼建立聚集索引有什麼樣的技巧哪？首先我們強調一點，聚集索引和主鍵是兩碼事，不可混爲一談，它們分別是表結構的兩個重要的機制，有共同的特性，是數據表的重要部分構成，但是兩者在應用上存在着本質的區別，雖然 SQL Server 在你不指定聚集索引時，會默認爲主鍵就是聚集索引，但是仍然要記住聚集索引和主鍵儘量區分對待，聚集索引的建立主要是從數據的讀取效率來考慮的，比如說人員信息表，設計上主鍵一般是人員編號，但是我們在利用人員信息表的時候，一般都會以姓名來過濾或排序，所以我們一般把聚集索引建立在姓名的字段上。
既然提到了主鍵，在這裏簡單描述一下主鍵 ( 看好了，說的是主鍵 ) ，主鍵是數據庫設計的主要部分，它是數據正確性和完整性的保證，建立主鍵時我們應該考慮數據庫的第三範式的定義和要求，即所有字段內容都與主鍵有直接關聯，而沒有間接關聯，同時主鍵也是用來唯一定義表數據的單一記錄，選擇主鍵時，要堅持唯一、最小、不可爲 NULL 、易獲取、基本不變更等條件。
再談非聚集索引，非聚集索引從結構上來說，他是完全獨立於數據表之外的結構，其子葉層存放數據存在着兩種類型：書籤和聚集索引的鍵值，原則是根據表是否存在聚集索引來區別的。如果表沒有建立聚集索引那麼子葉層存放的字段鍵值和指向數據表符合鍵值記錄的 Row ID ，也就是說文檔編號、分頁編號與頁內記錄編號所組合的值 (slot 編號 ) ，即 Heap 數據表。而直接通過 Row ID 來獲取數據，就是書籤查找，稱爲 bookmark lookup 。一般的非聚集索引都是要結合聚集索引的，否則只使用非聚集索引可能還會導致數據檢索的緩慢，所以要儘量保證數據表的聚集索引的存在和合理性。非聚集索引在一個表上可以存在 249 個，但是建議每個表的聚集索引不要超過 10 個。
瞭解了上述內容後，我們在建立索引的時候，就可以從整體上去考慮如何建立聚集索引和非聚集索引了。
首先，索引是用來幫助在大數據量的表中查找少量數據而建立的，所以聚集索引的結構所佔空間應遠遠小於數據庫表本身，想想如果一本書 400 頁，目錄就有 300 頁，你會看目錄嗎？
其次，索引鍵值的重複性越低越好。好比我們在一本書裏面用“的”去找尋，幾乎每頁都有一大堆，重複性極高，索引會反覆在前後頁面讀取，還不如直接遍歷效率高。
總之，建立索引一般要遵循數據類型儘量爲整型、數據本身儘量唯一、不可爲空值等原則。
最後強調，建立索引後，數據的增刪改會造成索引的自動維護，所以建立合理的索引就要求特別高，另外爲保證數據的增刪改的效率，建議類似實時查詢、實時監控之類的在反覆讀取數據，但查詢結果不要求非常準確的時候，可以在 SELECT 的語句上增加髒讀的關鍵字，以便提高總體的數據庫效率。
羅嗦了很多，不知道大家是越看越糊塗，請批評指正！下一節，嘮叨一下索引的維護，望關注。