索引是以表列為基礎的數據庫對象。索引中保存著表中排序的索引列，並且紀錄了索引列在數據庫表中的物理存儲位置，實現了表中數據的邏輯排序。通過索引，可以加快數據的查詢速度和減少系統的響應時間;可以使表和表之間的連接速度加快。
但是，不是在任何時候使用索引都能夠達到這種效果。若在不恰當的場合下，使用索引反而會事與願違。所以，在SQL Server數據庫中使用索引的話，還是需要遵守一定的規則。筆者覺得，主要是需要遵守六大鐵律。
鐵律一：天下沒有免費的午餐，使用索引是需要付出代價的。
索引的優點有目共睹，但是，卻很少有人關心過采用索引所需要付出的成本。若數據庫管理員能夠對索引所需要付出的代價有一個充分的認識，也就不會那麼隨意到處建立索引了。
仔細數數，其實建立索引的代價還是蠻大的。如創建索引和維護索引都需要花費時間與精力。特別是在數據庫設計的時候，數據庫管理員為表中的哪些字段需要建立索引，要調研、要協調。如當建有索引的表中的紀錄又增加、刪除、修改操作時，數據庫要對索引進行重新調整。雖然這個工作數據庫自動會完成，但是，需要消耗服務器的資源。當表中的數據越多，這個消耗的資源也就越多。如索引是數據庫中實際存在的對象，所以，每個索引都會占用一定的物理空間。若索引多了，不但會占用大量的物理空間，而且，也會影響到整個數據庫的運行性能。
可見，數據庫管理員若要采用索引來提高系統的性能，自身仍然需要付出不少的代價。數據庫管理員現在要考慮的就是如何在這兩個之間取得一個均衡。或者說，找到一個回報與投入的臨界點。
鐵律二：對於查詢中很少涉及的列或者重復值比較多的列，不要建立索引。
在查詢的時候，如果我們不按某個字段去查詢，則在這個字段上建立索引也是浪費。如現在有一張員工信息表，我們可能按員工編號、員工姓名、或者出身地去查詢員工信息。但是，我們往往不會按照身份證號碼去查詢。雖然這個身份證號碼是唯一的。此時，即使在這個字段上建立索引，也不能夠提高查詢的速度。相反，增加了系統維護時間和占用了系統空間。這簡直就是搬起石頭砸自己的腳呀。
另外，如上面的員工信息表，有些字段重復值比較多。如性別字段主要就是“男”、“女”;職位字段中也是有限的幾個內容。此時，在這些字段上添加索引也不會顯著的增加查詢速度，減少用戶響應時間。相反，因為需要占用空間，反而會降低數據庫的整體性能。
數據庫索引管理中的第二條鐵律就是，對於查詢中很少涉及的列或者重復值比較多的列，不要建立索引。
鐵律三：對於按范圍查詢的列，最好建立索引。
在信息化管理系統中，很多時候需要按范圍來查詢某些交易記錄。如在ERP系統中，經常需要查詢當月的銷售訂單與銷售出貨情況，這就需要按日期范圍來查詢交易記錄。如有時候發現庫存不對時，也需要某段時期的庫存進出情況，如5月1日到12月3日的庫存交易情況等等。此時，也是根據日期來進行查詢。
對於這些需要在指定范圍內快速或者頻繁查詢的數據列，需要為其建立索引。因為索引已經排序，其保存的時候指定的范圍是連續的，查詢可以利用索引的排序，加快查詢時間，減少用戶等待時間。
不過，若雖然可能需要按范圍來進行查詢，但是，若這個范圍查詢條件利用的不多的情況下，最好不好采用索引。如在員工信息表中，可能需要查詢2008年3月份以前入職的員工明細，要為他們增加福利。但是，由於表中記錄不多，而且，也很少進行類似的查詢。若維這個字段建立索引，雖然無傷大雅，但是很明顯，索引所獲得的收益要低於其成本支出。對數據庫管理員來說，是得不償失的。
再者，若采用范圍查詢的話，最好能利用TOP關鍵字來限制一次查詢的結果。如第一次按順序只顯示前面的500條記錄等等。把TOP關鍵字跟范圍一起使用，可以大大的提高查詢的效率。
