1. 程式人生 > >如果判斷是否需要建立索引

如果判斷是否需要建立索引

1、較頻繁的作為查詢條件的欄位應該建立索引.

2、唯一性太差的欄位不適合單獨建立索引,即使頻繁作為查詢條件:

唯一性太差的欄位:如狀態欄位,型別欄位等。這些欄位即使建立了單獨的索引,MySQL Query Optimizer大多數也不會選擇使用,如果什麼時候

     選擇了這種索引,可能會帶來極大的效能問題。由於索引欄位中每個值都含有大量的記錄,那麼儲存引擎在根據索引訪問資料的時候會帶來大量的隨機IO,甚至有時候可能還好出現大量的重複IO

       3、更新非常頻繁的欄位不適合建立索引:

     跟新欄位資料,同時還要更新索引的資料,以確保索引資訊是準確的,這會增加IO訪問量較大的增加,不僅僅影響更新query的響應時間,還會影響真個儲存系統的資源消耗,加大儲存系統的負責。

單一索引還是複合索引

對於多個where條件的資料,組合索引會比單一索引的查詢效率要高,因為通過單一索引所能過濾的資料並不完整,和通過組合索引相比,儲存引擎需要訪問更多的記錄。

但是組合索引在多個欄位中存在,更新的頻率會帶來一定效能消耗。

       對於建立多個單鍵索引,MYSQL Query  Optimizer大多數時候只會選擇一個單鍵值的索引,然後放棄其他索引。即使他選擇了同時利用兩個或者更多的索引通過INDEX_MERGE來優化查詢,可能所收到的效果並不會比選擇其中某一個單鍵值索引高效。

因為如果選擇了INDEX_MERGE來優化查詢,就需要訪問多個索引,同時還要將通過訪問到的幾個索引進行merge操作,所帶來的成本可能反而會比選擇其中一個最有效的索引來完成查詢更高。

在建立組合索引並不是說將查詢條件中所有欄位放在一個索引中,我們還應該儘量讓一個索引被多個query語句使用,儘量減少同一個表上面索引的數量,減少因為資料更新所帶來的索引更新成本。同時還可以減少因為索引所帶來的儲存空間的消耗。

大多數場景下比較適合:

1、對於單鍵索引,儘量選擇針對當前query過濾性更好的索引;

2、在選擇組合索引的時候,當前query中過濾性最好的欄位在索引欄位順序中排列越靠前越好;

3、在選擇組合索引的時候,儘量選擇可以能夠包含當前query的where子句中更多欄位索引;

4、儘可能通過分析統計資訊和調整query的寫法來達到選擇合適索引的目的而減少通過使用Hint人為控制索引的選擇,因為這會是後期的維護成本增加,同時增加維護所帶來的潛在風險。