注冊/登錄,歡迎光臨!
加入收藏設為首頁網站地圖
您當前的位置:辛勤IT網 >> 數據庫 >> mysql >> Mysql數據庫是否需要創建索引的判定標準
熱門:word | excel | powerpoint

Mysql數據庫是否需要創建索引的判定標準

2012/11/28 10:39:44 所屬分類:數據庫 - mysql
內容提要:Mysql數據庫是否需要創建索引的判定標準,實際上,并沒有一個非常明確的定律可以清晰地定義什么字段應該創建索引,什么字段不該創建索引。因為應用場景實在是太復雜,存在太多的差異。

    實際上,并沒有一個非常明確的定律可以清晰地定義什么字段應該創建索引,什么字段不該創建索引。因為應用場景實在是太復雜,存在太多的差異。當然,還是仍然能夠找到幾點基本的判定策略來幫助分析的。

    1、較頻繁的作為查詢條件的字段應該創建索引

    提高數據查詢檢索的效率最有效的辦法就是減少需要訪問的數據量,我們知道索引正是減少通過索引鍵字段作為查詢條件的Query的IO量之最有效手段。所以一般來說應該為較為頻繁的查詢條件字段創建索引。

    2、唯一性太差的字段不適合單獨創建索引,即使頻繁作為查詢條件

    唯一性太差的字段主要是指哪些呢?如狀態字段、類型字段等這些字段中存放的數據可能總共就是那么幾個或幾十個值重復使用,每個值都會存在于成千上萬或更多的記錄中。碎玉這類字段,完全沒有必要創建單獨的索引。因為即使創建了索引,MySQL Query Optimizer大多數時候也不會去選擇使用,如果什么時候MySQL Query Optimizer選擇了這種索引,那么非常遺憾地告訴你,這可能會帶來極大的性能問題。由于索引字段中每個值都含有大量的記錄,那么存儲引擎在根據索引訪問數據的時候會帶來大量的隨機IO,甚至有些時候還會出現大量的重復IO。

    這主要是由于數據基于索引掃描的特點引起的。當我們通過索引訪問表中數據時,MySQL會按照索引鍵的鍵值順序來依序訪問。一般來說,每個數據頁中大都會存放多條記錄,但是這些記錄可能大多數都不會和你所使用的索引鍵的鍵值順序一致。

    假如有以下場景,我們通過索引查找鍵值為A和B的某些數據。在通過A鍵值找到第一條滿足要求的記錄后,會讀取這條記錄所在的X數據頁,然后繼續往下查找索引,發現A鍵值所對應的另外一條記錄也滿足要求,但是這條記錄不在X數據頁上,而在Y數據頁上,這時候存儲引擎就會丟棄X數據頁,而讀取Y數據頁。如此繼續一直到查找完A鍵值所對應的所有記錄。然后輪到B鍵值了,這時發現正在查找的記錄又在X數據頁上,可之前讀取的X數據頁已經被丟棄了,只能再次讀取X數據頁。這時候,實際上已經重復讀取X數據頁兩次了。在繼續往后的查找中,可能還會出現一次又一次的重復讀取,這無疑給存儲引擎極大地增加了IO訪問量。

    不僅如此,如果一個鍵值對應了太多的數據記錄,也就是說通過該鍵值會返回占整個表比例很大的記錄時,由于根據索引掃描產生的都是隨機IO,其效率比進行全表掃描的順序IO效率低很多,即使不會出現重復IO的讀取,同樣會造成整體IO性能的下降。

    很多比較有經驗的Query調優專家經常說,當一條Query返回的數據超過了全表的15%時,就不應該再使用索引掃描來完成這個Query了。對于15%這個數字我們并不能判斷是否很準確,但是至少側面證明了唯一性太差的字段并不適合創建索引。

    3、更新非常頻繁的字段不適合創建索引

    索引中的字段被更新的時候,不僅要更新表中的數據,還要更新索引數據,以確保索引信息是準確的。這個問題致使IO訪問量較大增加,不僅僅影響了更新Query的響應時間,還影響了整個存儲系統的資源消耗,加大了整個存儲系統的負載。

    當然,并不是存在更新的字段就不適合創建索引,從判定策略的用語上也可以看出,是“非常頻繁”的字段。到底什么樣的更新頻率 應該算是“非常頻繁”呢?每秒?每分鐘?還是每小時呢?說實話,還真難定義。很多時候是通過比較同一時間段內被更新的次數和利用該字段作為條件的查詢次數來判斷的,如果通過該字段的查詢并不是很多,可能幾個小時或是更長才會執行一次,更新反而比查詢更頻繁,那這樣的字段肯定不適合創建索引。反之,如果我們通過該字段的查詢比較頻繁,但更新并不是特別多,比如查詢幾十次或更多才可能會產生一次更新,那我個人覺得更新所帶來的附加成本也是可以接受的。

    4、不會出現在WHERE子句中的字段不該創建索引

    關于這一點我想不用分析大家都知道了。

數據庫 | mysql
最近更新
推薦信息
關于我們 | 聯系方式 | 對話本站 | 版權聲明 | 所有信息
福建体彩31选7走势图开奖7