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對應的磁盤位置都還沒有修改，屬於臟頁，之后各自刷回自己的物理數據，就是另外一個過程了。