1. 現象
表結構如下
CREATE TABLE `ACT_HI_INST` ( `ID` varchar(64) COLLATE utf8_bin NOT NULL COMMENT '主鍵', `INST_ID_` varchar(64) COLLATE utf8_bin NOT NULL COMMENT '流程例項id', `BUSINESS_KEY_` varchar(255) COLLATE utf8_bin DEFAULT '' COMMENT '流程編號', `CREATE_TIME_` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '建立時間', `UPDATE_TIME_` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '建立時間', PRIMARY KEY (`ID`), UNIQUE KEY `UIDX_INST` (`INST_ID_`), UNIQUE KEY `UIDX_BKEY` (`BUSINESS_KEY_`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin
執行下面語句, 發現沒有走索引
explain SELECT * FROM ACT_HI_INST hi ORDER BY hi.BUSINESS_KEY_ DESC;
select count(*) from ACT_HI_INST ; -- 4332
同時我們發現rows與實際表的數量存在差異,使用下面語句重新統計索引資訊, 更正統計資訊, 更新之後發現 rows 就資料表的數量基本一致(不完全一樣是因為rows是取樣統計而來的)。
analyze table ACT_HI_INST;
也就是說對於下面這條語句,儘管BUSINESS_KEY_ 上有索引,MySQL還是選擇了全表掃描。為什麼會這樣呢?
SELECT * FROM ACT_HI_INST hi ORDER BY hi.BUSINESS_KEY_ DESC;
2. 猜想
我猜想原因是 因為MySQL認為即使 使用 BUSINESS_KEY_ 索引樹進行查詢,不需要排序,但是最後仍然需要回表,回表的次數 == 表的大小,這種代價比全表掃描然後排序的代價更大。
3. 驗證
為了驗證我的猜想,我加上在SQL語句最後加上 LIMIT 10 。如下所示
explain SELECT * FROM ACT_HI_INST hi ORDER BY hi.BUSINESS_KEY_ DESC limit 10;
果然我們看到加上 LIMIT 的語句走了索引。因為這個時候MySQL認為回表的代價比排序的代價更小,所以這個時候選擇了走 BUSINESS_KEY_ 索引。
除了上面這種方式可以驗證我的猜想,還有一種方式,如下所示。我們只查詢BUSINESS_KEY_ 。
因為此時葉子節點就包含我們需要查詢的欄位,這個時候不需要再回表,所以MySQL選擇BUSINESS_KEY_ 代價最小。
explain SELECT hi.BUSINESS_KEY_ FROM ACT_HI_INST hi ORDER BY hi.BUSINESS_KEY_ DESC ;
4. 補充
這部分主要來源於極客時間林曉斌老師的《MySQL實戰45講》第16講
order by a
如果 a 欄位上有索引,MySQL innodb引擎是按照上訴的方式進行選擇。如果a欄位上沒有索引,MySQL innodb引擎 就會有兩種排序方式:
全欄位排序 和 rowid 排序。
全欄位排序:將所有要選擇的欄位加入到sort_buffer中,然後在記憶體或者外部進行排序。如果能在記憶體中進行排序就在記憶體中進行排序。
如果要排序的資料量小於 sort_buffer_size,排序就在記憶體中完成。但如果排序資料量太大,記憶體放不下,則不得不利用磁碟臨時檔案輔助排序。
如果查詢要返回的欄位很多的話,那麼 sort_buffer 裡面要放的欄位數太多,這樣記憶體裡能夠同時放下的行數很少,要分成很多個臨時檔案,排序的效能會很差。這個時候MySQL就會採用rowId排序。
rowid排序:MySQL取出需要排序的欄位和ID放入sort_buffer中進行排序,最後按照排序的結果,通過ID回表,返回資料到客戶端。
MySQL 的一個設計思想是如果記憶體夠,就要多利用記憶體,儘量減少磁碟訪問。所以對應sort_buffer足夠大的情況,MySQL會優選選擇全欄位排序。