導讀:2SEO優化很多朋友可能都正在犯下面所說的性能優化誤區了，有需要的朋友可以參考一下Sql Server查詢性能優化之走出索引的誤建設網站建設網站公司。

據了解絕大多數開發人員對于索引的理解都是一知半解，局限于大多數日常工作沒有機會、也什么沒有必要去關心、了解索引，實在哪天某個查詢太慢了找到查詢條件建個索引就ok，哪天又有個查詢慢了，再建立個索引就是，或者干脆把整個查詢SQL直接發給DBA，讓DBA直接幫忙優化了，所以造成的狀況就是開發人員對于索引的理解、認識很局限，以下就把我個人對于索引的理解及淺薄認識和大家分享下，希望能解除一些網站建設制作大家的疑惑，一起走出索引的誤區 誤區1.在表上建立了索引，在查詢時用到了索引的列，索引就一定會生效 　　首先明確下這樣的觀點是錯誤的，SQL Server查詢優化器是基于開銷進行選擇的優化器，通過一系列復雜判斷來決定是否使用索引、使用什么類型索引、使用那個索引。SQL Server內部維護著索引列上的數據的統計，統計信息會隨著索引列內容的變化而變化，索引的有效期完全取決于索引列上的統計信息，隨著數據的變化關于索引的檢索機制也隨之變化。對于查詢優化器來說始終保持查詢開銷最低始終是其的不二選擇，如果一個非聚集索引的列上有大量的重復值，那么這個索引就不會有什么存在的意義，這也是為什么不建議在類似性別，bit類型上面建立非聚集索引的原因。 　　說到這里可能會有人疑惑，我在性別列上建一個索引，性別只有兩個值男、女，當我我們查詢條件中有性別這個字段時最起碼會過濾掉一半的數據，能大幅縮小我們需要檢索的數據范圍，怎么會沒用呢？(事實上這也是我曾經困惑的地方)，對我們理解的沒錯，比如說Users表性別列Gender上建立索引IX_Gender，執行select Gender from Users where Gender='男' ，這個查詢效率非常高而且也成功使用了索引IX_Gender，然而我們這樣寫SQL的時候少之又少，更多的我們會寫這樣的SQL:select UserID,UserName,網站建設多少錢Phone,Email from Users where Gender='男' 這時再去看看查詢計劃根本沒用使用索引IX_Gender，而是進行了一個聚集索引掃描或者表掃描，查詢條件where Gender='男' 明明在IX_Gender里面定義了，為什么沒使用呢，這一切罪惡的根源就在于書簽查找(RID、鍵查找)，好了關于書簽查找不是我們要討論的話題，在這里只想告訴大家，索引不是萬能的，索引不是創建了就一定有效。 誤區2.聚集索引掃描用到了聚集索引索引，所以性能很高 　　一般來說我們可以認為聚集索引是效率最高的索引，但聚集索引掃描絕不代表高效，本質上聚集索引掃描就是表掃營銷型網站建設描，一般出現掃描字樣時代表缺少索引或者索引無效，所以我們日常應用中應該避免在查詢計劃中看到掃描字樣，更多的出現聚集索引查找、索引查找才真正的使用到了索引，才是王道。 誤區3.聚集索引掃描(表掃描)是全表掃描，所以只要出現了表掃描就一定代表性能低下 　　在誤區2中我們說到應該盡量避免出現聚集索引掃描或者表掃描，這是我們必須要堅持的原則，但這并不代表這出現表掃描就一定性能低下，有些情況下表掃描反而比索引查找有著更高的效率(一般出現在返回數據量較大，出現大量書簽查找的情況下) 誤區4.查詢計劃中看到了鍵查找或者RID查找時有著很高的性能 　　鍵查找和RID查找統稱為書簽查找，和錯誤認識正好相反，出現書簽查找反而代表著性能低下，有些情況下甚至有著比表掃描更低的效率，因此我們應該盡量避免書簽查找。在返回數據量較小時，書簽查找對性能影響不大，若返回數據量較大，書簽查找會嚴重影響查詢性能，因此我們建立索引時應該盡量覆蓋要返回的所有列，當然索引列數是有限的而且也不能單純的為了避免書簽查找而在索引中包含大量的列，可以使用覆蓋索引來解決書簽查找問題，或者需要大數據量返回時盡量使用聚集索引；同時這也是為什么常聽說的不要使用select *,而只選擇需要的列進行輸出，因為select *很容易導致書簽查找，畢竟我們不打可能在所有列上建立索引，也不可能所有查詢都使用聚集索引(使用聚集索引和表掃描時不存在書簽查找) 誤區5.查詢開銷統計中的邏輯讀次數是讀取的記錄數 　　天真的我曾經也這么認為，查詢計劃中邏輯讀次數就是讀取的記錄數，然而看我們的查詢4.1全表掃描返回830行數據，為啥邏輯讀只有22次，而查詢4.5同樣是返回830行數據，邏輯讀為啥1724次呢，一次讀取一條的話邏輯讀22次最多返回22行數據，邏輯讀1724次的話應該返回1724條數據吧，有點小暈，這里解釋下邏輯讀次數是指讀取的頁面數，一個面8KB，8個頁面構成一個區64KB，對于我們的示例表來說22個頁面足以存下所有數據，所以表掃描時只需讀取22次就可以了，那查詢4.5為啥讀取了1724次呢，就算一個頁面就一條數據按理說最多800多次也可以讀取完畢了，這是因為Sql Server對數據讀取的最小單位就是頁，哪怕讀取一條數據也需要讀取整頁數據，而非聚集索引的讀是隨機讀哪怕多條記錄在同一頁上也會導致多次重復讀取，外加書簽查找導致了這么多的邏輯讀，這也是為什么非聚集索引不適合讀取大量數據的原因之一。 我們以Northwind數據庫表Orders表為示例進行下演示 　1.先將Orders表的索引全部刪除 　4.在OrderID上面創建聚集索引，索引列為OrderID　　

關鍵詞標簽: 誤區 索引