從上圖看到使用name,age,pos建立了一個復合索引，并且排序順序為name->age->pos。使用此表結構來說一下索引優化和索引失效。

大概總結分為一下幾點

• 全值匹配我最愛(怎么建怎么用)

從三條語句中看出三條語句都用到了索引，而且type類型為ref，where后面的條件越來越多精度越來越高，精度越來越高帶來的就是長度和花費的代價也就越來越多(key_len由74-78-140，ref從一個常量變為3個常量)。但是來看下面的情況。

綜合上述，我們建的索引是nameAgePos，但是沒有了開頭的name，如果打破前面創建的索引規則，把where條件剔除掉，使用age和pos或pos來查詢的話，緊接著看到的就是全表掃描。沒有使用到索引。結合我們下面的說法，就是違背了最佳作前綴法則

• 最佳作前綴法則

如果索引了多列，要遵守最左前綴法則。指的是查詢從索引的最左前列開始并且 不跳過索引中的列。綜合起來口訣：帶頭大哥不能死。

我們可以這么聯想，我們創建的索引是nameAgePos，name就好比火車的車頭，而后面的age和pos就是車廂，火車頭自己可以跑，所以說，單獨有name的時候索引沒有失效。有火車頭帶著一個車廂也能跑得起來(name,age)。沒了車頭車廂也不用說只能晾干了。

再來看一個例子

我們把中間的age去掉，顯而易見看到理論和實際都使用了索引，ref也是使用常量。但是兩個key_len都是62，說明索引并不是全職匹配而是部分匹配。綜合口訣：中間兄弟不能斷。

• 不在索引列上做任何操作(計算、函數、(自動or手動)類型轉換)，會導致索引失效而轉向全表掃描

相同結果，做出的東西是一樣的，但是分析出的性能卻差得多。口訣：索引列上少計算

• 存儲引擎不能使用索引中范圍條件右面的列

我們可以看到索引執行的四條中，前三條的type類型都是ref，根據where條件的精度key_len也都在增加，最后一條由于age使用了范圍搜索，導致age后的查詢條件失效，key_len還是66。綜合口訣：范圍之后全失效。

• 盡量使用覆蓋索引(只訪問索引的查詢（索引列和查詢列一直))，減少select *。

首先看第一條和第二條的對比，使用*和使用索引列去查詢返回的Extra是多了一個using index（用什么取什么會比寫*要好很多）。第三條雖然使用了范圍查詢導致后面的查詢條件失效，但是age確是從索引上拿此時key_len的長度為62，而且type也沒有使用range而是ref，效果有所提升。第四條同樣是根據name,age,pos查詢，條件為等于的type相同，key_len確為66，ref為兩個常量，此時的查詢也比較優秀。還有一種情況只需要個別字段(第五條)，也可以使用using index。

• MySQL在使用不等于(!= 或<>)的時候無法使用索引會導致全表掃描

這個時候不能因為會導致索引失效，而不寫，但是得知道這種情況下會導致失效，改寫的時候還是也要寫。最重要還是看生產環境、業務、技術。具體業務具體分析。

• is null,is not null 也無法使用索引

• like以通配符開頭('%abc...')mysql索引失效回變成全表掃描的操作

從上述結果看出，只有百分號在右面的才能避免索引失效。且type是range。綜合口訣：百分like加右面。

那么如何解決百分號在左邊導致全表掃描的問題呢？

我們的解決辦法是使用覆蓋索引 like字符串時索引失效

• 字符串不加單引號索引失效

• 少用or，用它來連接時回索引失效

以上就是索引優化的一些方法，根據上面的例子總結出的一些口訣如下：

全值匹配我最愛，最左前綴要遵守

帶頭大哥不能死，中間兄弟不能斷(永遠要符合最佳左前綴原則)

索引列上無計算(計算、函數、(自動、手動)類型轉換)，范圍之后全失效

like百分寫最右，覆蓋索引不寫星

不等控制還有or，索引失效要少用

var引號不能丟，SQL優化也不難

小例子：

總結

以上是生活随笔為你收集整理的mysql性能优化金字塔法则pdf_MySQL索引优化2-优化法则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。