10 | MySQL爲何有時候會選錯索引？

前面咱們介紹過索引，你已經知道了在MySQL中一張表實際上是能夠支持多個索引的。可是，你寫SQL語句的時候，並無主動指定使用哪一個索引。也就是說，使用哪一個索引是由MySQL來肯定的。

不知道你有沒有碰到過這種狀況，一條原本能夠執行得很快的語句，卻因爲MySQL選錯了索引，而致使執行速度變得很慢？

咱們一塊兒來看一個例子吧。

咱們先建一個簡單的表，表裏有a、b兩個字段，並分別建上索引：

CREATE TABLE `t` (
`id` int(11) NOT NULL,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `a` (`a`),
KEY `b` (`b`)
) ENGINE=InnoDB；

而後，咱們往表t中插入10萬行記錄，取值按整數遞增，即：(1,1,1)，(2,2,2)，(3,3,3) 直到(100000,100000,100000)。

我是用存儲過程來插入數據的，這裏我貼出來方便你復現：

delimiter ;;
create procedure idata()
begin
declare i int;
set i=1;
while(i<=100000)do
insert into t values(i, i, i);
set i=i+1;
end while;
end;;
delimiter ;
call idata();

接下來，咱們分析一條SQL語句：

mysql> select * from t where a between 10000 and 20000;

你必定會說，這個語句還用分析嗎，很簡單呀，a上有索引，確定是要使用索引a的。

你說得沒錯，圖1顯示的就是使用explain命令看到的這條語句的執行狀況。

圖1 使用explain命令查看語句執行狀況

從圖1看上去，這條查詢語句的執行也確實符合預期，key這個字段值是’a’，表示優化器選擇了索引a。

不過別急，這個案例不會這麼簡單。在咱們已經準備好的包含了10萬行數據的表上，咱們再作以下操做。

圖2 session A和session B的執行流程

這裏，session A的操做你已經很熟悉了，它就是開啓了一個事務。隨後，session B把數據都刪除後，又調用了 idata這個存儲過程，插入了10萬行數據。

這時候，session B的查詢語句select * from t where a between 10000 and 20000就不會再選擇索引a了。咱們能夠經過慢查詢日誌（slow log）來查看一下具體的執行狀況。

爲了說明優化器選擇的結果是否正確，我增長了一個對照，即：使用force index(a)來讓優化器強制使用索引a（這部份內容，我還會在這篇文章的後半部分中提到）。

下面的三條SQL語句，就是這個實驗過程。

set long_query_time=0;
select * from t where a between 10000 and 20000; /*Q1*/
select * from t force index(a) where a between 10000 and 20000;/*Q2*/

• 第一句，是將慢查詢日誌的閾值設置爲0，表示這個線程接下來的語句都會被記錄入慢查詢日誌中；
• 第二句，Q1是session B原來的查詢；
• 第三句，Q2是加了force index(a)來和session B原來的查詢語句執行狀況對比。

如圖3所示是這三條SQL語句執行完成後的慢查詢日誌。

圖3 slow log結果

能夠看到，Q1掃描了10萬行，顯然是走了全表掃描，執行時間是40毫秒。Q2掃描了10001行，執行了21毫秒。也就是說，咱們在沒有使用force index的時候，MySQL用錯了索引，致使了更長的執行時間。

這個例子對應的是咱們日常不斷地刪除歷史數據和新增數據的場景。這時，MySQL居然會選錯索引，是否是有點奇怪呢？今天，咱們就從這個奇怪的結果提及吧。

優化器的邏輯

在第一篇文章中，咱們就提到過，選擇索引是優化器的工做。

而優化器選擇索引的目的，是找到一個最優的執行方案，並用最小的代價去執行語句。在數據庫裏面，掃描行數是影響執行代價的因素之一。掃描的行數越少，意味着訪問磁盤數據的次數越少，消耗的CPU資源越少。

固然，掃描行數並非惟一的判斷標準，優化器還會結合是否使用臨時表、是否排序等因素進行綜合判斷。

咱們這個簡單的查詢語句並無涉及到臨時表和排序，因此MySQL選錯索引確定是在判斷掃描行數的時候出問題了。

那麼，問題就是：掃描行數是怎麼判斷的？

MySQL在真正開始執行語句以前，並不能精確地知道知足這個條件的記錄有多少條，而只能根據統計信息來估算記錄數。

這個統計信息就是索引的「區分度」。顯然，一個索引上不一樣的值越多，這個索引的區分度就越好。而一個索引上不一樣的值的個數，咱們稱之爲「基數」（cardinality）。也就是說，這個基數越大，索引的區分度越好。

咱們可使用show index方法，看到一個索引的基數。如圖4所示，就是表t的show index 的結果 。雖然這個表的每一行的三個字段值都是同樣的，可是在統計信息中，這三個索引的基數值並不一樣，並且其實都不許確。

圖4 表t的show index 結果

那麼，MySQL是怎樣獲得索引的基數的呢？這裏，我給你簡單介紹一下MySQL採樣統計的方法。

爲何要採樣統計呢？由於把整張表取出來一行行統計，雖然能夠獲得精確的結果，可是代價過高了，因此只能選擇「採樣統計」。

採樣統計的時候，InnoDB默認會選擇N個數據頁，統計這些頁面上的不一樣值，獲得一個平均值，而後乘以這個索引的頁面數，就獲得了這個索引的基數。

而數據表是會持續更新的，索引統計信息也不會固定不變。因此，當變動的數據行數超過1/M的時候，會自動觸發從新作一次索引統計。

在MySQL中，有兩種存儲索引統計的方式，能夠經過設置參數innodb_stats_persistent的值來選擇：

• 設置爲on的時候，表示統計信息會持久化存儲。這時，默認的N是20，M是10。
• 設置爲off的時候，表示統計信息只存儲在內存中。這時，默認的N是8，M是16。

因爲是採樣統計，因此無論N是20仍是8，這個基數都是很容易不許的。

但，這還不是所有。

你能夠從圖4中看到，此次的索引統計值（cardinality列）雖然不夠精確，但大致上仍是差很少的，選錯索引必定還有別的緣由。

其實索引統計只是一個輸入，對於一個具體的語句來講，優化器還要判斷，執行這個語句自己要掃描多少行。

接下來，咱們再一塊兒看看優化器預估的，這兩個語句的掃描行數是多少。

圖5 意外的explain結果

rows這個字段表示的是預計掃描行數。

其中，Q1的結果仍是符合預期的，rows的值是104620；可是Q2的rows值是37116，誤差就大了。而圖1中咱們用explain命令看到的rows是隻有10001行，是這個誤差誤導了優化器的判斷。

到這裏，可能你的第一個疑問不是爲何不許，而是優化器爲何放着掃描37000行的執行計劃不用，卻選擇了掃描行數是100000的執行計劃呢？

這是由於，若是使用索引a，每次從索引a上拿到一個值，都要回到主鍵索引上查出整行數據，這個代價優化器也要算進去的。

而若是選擇掃描10萬行，是直接在主鍵索引上掃描的，沒有額外的代價。

優化器會估算這兩個選擇的代價，從結果看來，優化器認爲直接掃描主鍵索引更快。固然，從執行時間看來，這個選擇並非最優的。

使用普通索引須要把回表的代價算進去，在圖1執行explain的時候，也考慮了這個策略的代價 ，但圖1的選擇是對的。也就是說，這個策略並無問題。

因此冤有頭債有主，MySQL選錯索引，這件事兒還得歸咎到沒能準確地判斷出掃描行數。至於爲何會獲得錯誤的掃描行數，這個緣由就做爲課後問題，留給你去分析了。

既然是統計信息不對，那就修正。analyze table t 命令，能夠用來從新統計索引信息。咱們來看一下執行效果。

圖6 執行analyze table t 命令恢復的explain結果

這回對了。

因此在實踐中，若是你發現explain的結果預估的rows值跟實際狀況差距比較大，能夠採用這個方法來處理。

其實，若是隻是索引統計不許確，經過analyze命令能夠解決不少問題，可是前面咱們說了，優化器可不止是看掃描行數。

依然是基於這個表t，咱們看看另一個語句：

mysql> select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;

從條件上看，這個查詢沒有符合條件的記錄，所以會返回空集合。

在開始執行這條語句以前，你能夠先設想一下，若是你來選擇索引，會選擇哪個呢？

爲了便於分析，咱們先來看一下a、b這兩個索引的結構圖。

圖7 a、b索引的結構圖

若是使用索引a進行查詢，那麼就是掃描索引a的前1000個值，而後取到對應的id，再到主鍵索引上去查出每一行，而後根據字段b來過濾。顯然這樣須要掃描1000行。

若是使用索引b進行查詢，那麼就是掃描索引b的最後50001個值，與上面的執行過程相同，也是須要回到主鍵索引上取值再判斷，因此須要掃描50001行。

因此你必定會想，若是使用索引a的話，執行速度明顯會快不少。那麼，下面咱們就來看看究竟是不是這麼一回事兒。

圖8是執行explain的結果。

mysql> explain select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;

圖8 使用explain方法查看執行計劃 2

能夠看到，返回結果中key字段顯示，此次優化器選擇了索引b，而rows字段顯示須要掃描的行數是50198。

從這個結果中，你能夠獲得兩個結論：

1. 掃描行數的估計值依然不許確；

2. 這個例子裏MySQL又選錯了索引。

索引選擇異常和處理

其實大多數時候優化器都能找到正確的索引，但偶爾你仍是會碰到咱們上面舉例的這兩種狀況：本來能夠執行得很快的SQL語句，執行速度卻比你預期的慢不少，你應該怎麼辦呢？

一種方法是，像咱們第一個例子同樣，採用force index強行選擇一個索引。MySQL會根據詞法解析的結果分析出可能可使用的索引做爲候選項，而後在候選列表中依次判斷每一個索引須要掃描多少行。若是force index指定的索引在候選索引列表中，就直接選擇這個索引，再也不評估其餘索引的執行代價。

咱們來看看第二個例子。剛開始分析時，咱們認爲選擇索引a會更好。如今，咱們就來看看執行效果：

圖9 使用不一樣索引的語句執行耗時

能夠看到，本來語句須要執行2.23秒，而當你使用force index(a)的時候，只用了0.05秒，比優化器的選擇快了40多倍。

也就是說，優化器沒有選擇正確的索引，force index起到了「矯正」的做用。

不過不少程序員不喜歡使用force index，一來這麼寫不優美，二來若是索引改了名字，這個語句也得改，顯得很麻煩。並且若是之後遷移到別的數據庫的話，這個語法還可能會不兼容。

但其實使用force index最主要的問題仍是變動的及時性。由於選錯索引的狀況仍是比較少出現的，因此開發的時候一般不會先寫上force index。而是等到線上出現問題的時候，你纔會再去修改SQL語句、加上force index。可是修改以後還要測試和發佈，對於生產系統來講，這個過程不夠敏捷。

因此，數據庫的問題最好仍是在數據庫內部來解決。那麼，在數據庫裏面該怎樣解決呢？

既然優化器放棄了使用索引a，說明a還不夠合適，因此第二種方法就是，咱們能夠考慮修改語句，引導MySQL使用咱們指望的索引。好比，在這個例子裏，顯然把「order by b limit 1」 改爲 「order by b,a limit 1」 ，語義的邏輯是相同的。

咱們來看看改以後的效果：

圖10 order by b,a limit 1 執行結果

以前優化器選擇使用索引b，是由於它認爲使用索引b能夠避免排序（b自己是索引，已是有序的了，若是選擇索引b的話，不須要再作排序，只須要遍歷），因此即便掃描行數多，也斷定爲代價更小。

如今order by b,a 這種寫法，要求按照b,a排序，就意味着使用這兩個索引都須要排序。所以，掃描行數成了影響決策的主要條件，因而此時優化器選了只須要掃描1000行的索引a。

固然，這種修改並非通用的優化手段，只是恰好在這個語句裏面有limit 1，所以若是有知足條件的記錄， order by b limit 1和order by b,a limit 1 都會返回b是最小的那一行，邏輯上一致，才能夠這麼作。

若是你以爲修改語義這件事兒不太好，這裏還有一種改法，圖11是執行效果。

mysql> select * from (select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 100)alias limit 1;

圖11 改寫SQL的explain

在這個例子裏，咱們用limit 100讓優化器意識到，使用b索引代價是很高的。實際上是咱們根據數據特徵誘導了一下優化器，也不具有通用性。

第三種方法是，在有些場景下，咱們能夠新建一個更合適的索引，來提供給優化器作選擇，或刪掉誤用的索引。

不過，在這個例子中，我沒有找到經過新增索引來改變優化器行爲的方法。這種狀況其實比較少，尤爲是通過DBA索引優化過的庫，再碰到這個bug，找到一個更合適的索引通常比較難。

若是我說還有一個方法是刪掉索引b，你可能會以爲可笑。但實際上我碰到過兩次這樣的例子，最終是DBA跟業務開發溝通後，發現這個優化器錯誤選擇的索引其實根本沒有必要存在，因而就刪掉了這個索引，優化器也就從新選擇到了正確的索引。

小結

今天咱們一塊兒聊了聊索引統計的更新機制，並提到了優化器存在選錯索引的可能性。

對於因爲索引統計信息不許確致使的問題，你能夠用analyze table來解決。

而對於其餘優化器誤判的狀況，你能夠在應用端用force index來強行指定索引，也能夠經過修改語句來引導優化器，還能夠經過增長或者刪除索引來繞過這個問題。

你可能會說，今天這篇文章後面的幾個例子，怎麼都沒有展開說明其原理。我要告訴你的是，今天的話題，咱們面對的是MySQL的bug，每個展開都必須深刻到一行行代碼去量化，實在不是咱們在這裏應該作的事情。

因此，我把我用過的解決方法跟你分享，但願你在碰到相似狀況的時候，可以有一些思路。

你平時在處理MySQL優化器bug的時候有什麼別的方法，也發到評論區分享一下吧。

最後，我給你留下一個思考題。前面咱們在構造第一個例子的過程當中，經過session A的配合，讓session B刪除數據後又從新插入了一遍數據，而後就發現explain結果中，rows字段從10001變成37000多。

而若是沒有session A的配合，只是單獨執行delete from t 、call idata()、explain這三句話，會看到rows字段其實仍是10000左右。你能夠本身驗證一下這個結果。

這是什麼緣由呢？也請你分析一下吧。

你能夠把你的分析結論寫在留言區裏，我會在下一篇文章的末尾和你討論這個問題。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一塊兒閱讀。

上期問題時間

我在上一篇文章最後留給你的問題是，若是某次寫入使用了change buffer機制，以後主機異常重啓，是否會丟失change buffer和數據。

這個問題的答案是不會丟失，留言區的不少同窗都回答對了。雖然是隻更新內存，可是在事務提交的時候，咱們把change buffer的操做也記錄到redo log裏了，因此崩潰恢復的時候，change buffer也能找回來。

在評論區有同窗問到，merge的過程是否會把數據直接寫回磁盤，這是個好問題。這裏，我再爲你分析一下。

merge的執行流程是這樣的：

1. 從磁盤讀入數據頁到內存（老版本的數據頁）；

2. 從change buffer裏找出這個數據頁的change buffer 記錄(可能有多個），依次應用，獲得新版數據頁；

3. 寫redo log。這個redo log包含了數據的變動和change buffer的變動。

到這裏merge過程就結束了。這時候，數據頁和內存中change buffer對應的磁盤位置都尚未修改，屬於髒頁，以後各自刷回本身的物理數據，就是另一個過程了。