提升查詢效率，瞭解SQL的索引管理規則

索引是以表列爲基礎的數據庫對象。索引中保存着表中排序的索引列，而且紀錄了索引列在數據庫表中的物理存儲位置，實現了表中數據的邏輯排序。經過索引，能夠加快數據的查詢速度和減小系統的響應時間;可使表和表之間的鏈接速度加快。

　　可是，不是在任什麼時候候使用索引都可以達到這種效果。若在不恰當的場合下，使用索引反而會事與願違。因此，在SQL Server數據庫中使用索引的話，仍是須要遵照必定的規則。

　　規則一：天下沒有免費的午飯，使用索引是須要付出代價的

　　索引的優勢有目共睹，可是，卻不多有人關心過採用索引所須要付出的成本。若數據庫管理員可以對索引所須要付出的代價有一個充分的認識，也就不會那麼隨意處處創建索引了。

　　仔細數數，其實創建索引的代價仍是蠻大的。如建立索引和維護索引都須要花費時間與精力。特別是在數據庫設計的時候，數據庫管理員爲表中的哪些字段須要創建索引，要調研、要協調。如當建有索引的表中的紀錄又增長、刪除、修改操做時，數據庫要對索引進行從新調整。雖然這個工做數據庫自動會完成，可是，須要消耗服務器的資源。當表中的數據越多，這個消耗的資源也就越多。如索引是數據庫中實際存在的對象，因此，每一個索引都會佔用必定的物理空間。若索引多了，不但會佔用大量的物理空間，並且，也會影響到整個數據庫的運行性能。

　　可見，數據庫管理員若要採用索引來提升系統的性能，自身仍然須要付出很多的代價。數據庫管理員如今要考慮的就是如何在這兩個之間取得一個均衡。或者說，找到一個回報與投入的臨界點。

　　規則二：對於查詢中不多涉及的列或者重複值比較多的列，不要創建索引

　　在查詢的時候，若是咱們不按某個字段去查詢，則在這個字段上創建索引也是浪費。如如今有一張員工信息表，咱們可能按員工編號、員工姓名、或者出身地去查詢員工信息。可是，咱們每每不會按照×××號碼去查詢。雖然這個×××號碼是惟一的。此時，即便在這個字段上創建索引，也不可以提升查詢的速度。相反，增長了系統維護時間和佔用了系統空間。這簡直就是搬起石頭砸本身的腳呀。

　　另外，如上面的員工信息表，有些字段重複值比較多。如性別字段主要就是「男」、「女」;職位字段中也是有限的幾個內容。此時，在這些字段上添加索引也不會顯著的增長查詢速度，減小用戶響應時間。相反，由於須要佔用空間，反而會下降數據庫的總體性能。

　　數據庫索引管理中的第二條規則就是，對於查詢中不多涉及的列或者重複值比較多的列，不要創建索引。

　　規則三：對於按範圍查詢的列，最好創建索引

　　在信息化管理系統中，不少時候須要按範圍來查詢某些交易記錄。如在ERP系統中，常常須要查詢當月的銷售訂單與銷售出貨狀況，這就須要按日期範圍來查詢交易記錄。若有時候發現庫存不對時，也須要某段時期的庫存進出狀況，如5月1日到12月3日的庫存交易狀況等等。此時，也是根據日期來進行查詢。

　　對於這些須要在指定範圍內快速或者頻繁查詢的數據列，須要爲其創建索引。由於索引已經排序，其保存的時候指定的範圍是連續的，查詢能夠利用索引的排序，加快查詢時間，減小用戶等待時間。

　　不過，若雖然可能須要按範圍來進行查詢，可是，若這個範圍查詢條件利用的很少的狀況下，最好很差採用索引。如在員工信息表中，可能須要查詢2008 年3月份之前入職的員工明細，要爲他們增長福利。可是，因爲表中記錄很少，並且，也不多進行相似的查詢。若維這個字段創建索引，雖然無傷大雅，可是很明顯，索引所得到的收益要低於其成本支出。對數據庫管理員來講，是得不償失的。

　　再者，若採用範圍查詢的話，最好能利用TOP關鍵字來限制一次查詢的結果。如第一次按順序只顯示前面的500條記錄等等。把TOP關鍵字跟範圍一塊兒使用，能夠大大的提升查詢的效率。