MySQL之ORDER BY 詳細解析
1 概述
MySQL有兩種方式可以實現ORDER BY:
1.通過索引掃描生成有序的結果
2.使用檔案排序(filesort)
圍繞著這兩種排序方式,我們試著理解一下ORDER BY的執行過程以及回答一些常見的問題(下文僅討論InnoDB儲存引擎)。
2 索引掃描排序和檔案排序(filesort)簡介
我們知道InnoDB儲存引擎以B+樹作為索引的底層實現,B+樹的葉子節點儲存著所有資料頁而內部節點不存放資料資訊,並且所有葉子節點形成一個(雙向)連結串列。
舉個例子,假設userinfo表的userid欄位上有主鍵索引,且userid目前的範圍在1001~1006之間,則userid的索引B+樹如下(這裡只是為了舉例,下圖忽略了InnoDB資料頁預設大小16KB、雙向連結串列,並且假設B+樹度數為3、userid順序插入):
現在我們想按照userid從小到大的順序取出所有使用者資訊,執行以下SQL:
SELECT *
FROM userinfo
ORDER BY userid;
MySQL會直接遍歷上圖userid索引的葉子節點連結串列,不需要進行額外的排序操作。這就是用索引掃描來排序。
但如果userid欄位上沒有任何索引,圖1的B+樹結構不存在,MySQL就只能先掃表篩選出符合條件的資料,再將篩選結果根據userid排序。這個排序過程就是filesort。
下文將詳細介紹這兩種排序方式。
3 索引掃描排序執行過程分析
介紹索引掃描排序之前,先看看索引的用途
SQL語句中,WHERE
雖然索引能提高查詢效率,但在一條SQL裡,對於一張表的查詢 一次只能使用一個索引(注:排除發生index merge的可能性),也就是說當WHERE子句與ORDER BY子句要使用的索引不一致時,MySQL只能使用其中一個索引(B+樹)。
也就是說,一個既有WHERE又有ORDER BY的SQL中,使用索引有三個可能的場景:
只用於WHERE子句 篩選出滿足條件的資料
只用於ORDER BY子句 返回排序後的結果
既用於WHERE又用於ORDER BY,篩選出滿足條件的資料並返回排序後的結果
舉個例子,我們建立一張orderdetail表 記錄每一筆充值記錄的userid(使用者id)、money(充值金額)、create****time(充值時間),主鍵是自增id:
CREATE TABLE `order_detail` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userid` int(11) NOT NULL,
`money` float NOT NULL,
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `userid` (`userid`),
KEY `create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
寫指令碼插入100w行資料(InnoDB別用COUNT(*)查總行數,會掃全表,這裡只是為了演示):
SELECT COUNT(*) FROM order_detail;
+----------+
| COUNT(*) |
+----------+
| 1000000 |
+----------+
SELECT * FROM order_detail LIMIT 5;
+----+--------+-------+---------------------+
| id | userid | money | create_time |
+----+--------+-------+---------------------+
| 1 | 104832 | 3109 | 2013-01-01 07:40:38 |
| 2 | 138455 | 6123 | 2013-01-01 07:40:42 |
| 3 | 109967 | 7925 | 2013-01-01 07:40:46 |
| 4 | 166686 | 4307 | 2013-01-01 07:40:55 |
| 5 | 119837 | 1912 | 2013-01-01 07:40:58 |
+----+--------+-------+---------------------+
現在我們想取出userid=104832使用者的所有充值記錄,並按照充值時間create_time正序返回。
場景一 索引只用於WHERE子句
寫出如下SQL並EXPLAIN一下:
EXPLAIN
SELECT *
FROM order_detail
WHERE userid = 104832
ORDER BY create_time;
+------+-------------+--------------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table| type | possible_keys | key| key_len | ref | rows | Extra |
+------+-------------+--------------+------+---------------+--------+---------+-------+------+-----------------------------+
| 1 | SIMPLE| order_detail | ref | userid| userid | 4 | const | 8 | Using where; Using filesort |
+------+-------------+--------------+------+---------------+--------+---------+-------+------+-----------------------------+
key
列的值是userid,可以看出這條SQL會使用userid索引用作WHERE子句的條件過濾,而ORDER BY子句無法使用該索引,只能使用filesort來排序。這就是上文的第一個場景,整個執行流程大致如下:
先通過userid索引找到所有滿足WHERE條件的主鍵id(注:從b+樹根節點往下找葉子節點,時間複雜度為O(logN))
再根據這些主鍵id去主鍵索引(聚簇索引)找到這幾行的資料,生成一張臨時表(時間複雜度為O(M*logN),M是臨時表的行數)
對臨時表進行排序(時間複雜度O(M*logM),M是臨時表的行數)
由於本例中M的值可以大概參考 rows
列的值8,非常小,所以整個執行過程只花費0.00 sec。
場景二 索引只用於ORDER BY子句
接下來是上文的第二種場景,索引只用於ORDER BY子句,這即是索引掃描排序。
我們可以繼續使用上文的SQL,通過FORCE INDEX子句強制Optimizer使用ORDER BY子句的索引create_time:
EXPLAIN
SELECT *
FROM order_detail
FORCE INDEX (create_time)
WHERE userid = 104832
ORDER BY create_time;
+------+-------------+--------------+-------+---------------+-------------+---------+------+--------+-------------+
| id | select_type | table| type| possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+--------------+-------+---------------+-------------+---------+------+--------+-------------+
| 1 | SIMPLE| order_detail | index | NULL| create_time | 4 | NULL | 998056 | Using where |
+------+-------------+--------------+-------+---------------+-------------+---------+------+--------+-------------+
可以看到Extra欄位裡的Using filesort已經沒了,但是掃過的rows大概有998056行(準確的值應該是1000000行,InnoDB這一列只是估值)。這是因為索引用於ORDER BY子句時,會直接遍歷該索引的葉子節點連結串列,而不像第一種場景那樣從B+樹的根節點出發 往下查詢。執行流程如下:
從create_time索引的第一個葉子節點出發,按順序掃描所有葉子節點
根據每個葉子節點記錄的主鍵id去主鍵索引(聚簇索引)找到真實的行資料,判斷行資料是否滿足WHERE子句的userid條件,若滿足,則取出並返回
整個時間複雜度是O(M*logN),M是主鍵id的總數,N是聚簇索引葉子節點的個數(資料頁的個數)。本例中M的值為1000000,所以整個執行過程比第一種場景花了更多時間,同一臺機器上耗時1.34 sec。
上述兩個例子恰好說明了另一個道理:在某些場景下使用filesort比不使用filesort 效率更高。
場景三 索引既用於WHERE又用於ORDER BY
第三種情況發生在WHERE子句與ORDER BY子句能使用相同的索引時(如: WHERE userid > xxx ORDER BY userid),這樣就能省去第二種情況的回表查詢操作了。
因此,如果可能,設計索引時應該儘可能地同時滿足這兩種任務,這樣是最好的。 —-《高效能MySQL》
4 檔案排序(filesort)
關於filesort上文其實已經介紹過了一些。
filesort的名字起得很費解,讓人誤以為它會:將一張非常大的表放入磁碟再進行排序。其實不是這樣的,filesort**僅僅是排序而已,是否會放入磁碟看情況而定(filesort is not always bad and it does not mean that a file is saved on disk. If the size of the data is small, it is performed in memory.)。以下是《高效能MySQL》中對**filesort的介紹:
如果需要排序的資料量小於“排序緩衝區”,MySQL使用記憶體進行“快速排序”操作。如果記憶體不夠排序,那麼MySQL會先將資料分塊,可對每個獨立的塊使用“快速排序”進行排序,再將各個塊的排序結果放到磁碟上,然後將各個排好序的塊進行“歸併排序”,最後返回排序結果。
所以filesort是否會使用磁碟取決於它操作的資料量大小。
總結來說就是,filesort按排序方式來劃分 分為兩種:
1.資料量小時,在記憶體中快排
2.資料量大時,在記憶體中分塊快排,再在磁碟上將各個塊做歸併
資料量大的情況下涉及到磁碟io,所以效率會低一些。
根據回表查詢的次數,filesort又可以分為兩種方式:
1.回表讀取兩次資料(two-pass):兩次傳輸排序
2.回表讀取一次資料(single-pass):單次傳輸排序
兩次傳輸排序
兩次傳輸排序會進行兩次回表操作:第一次回表用於在WHERE子句中篩選出滿足條件的rowid以及rowid對應的ORDER BY的列值;第二次回表發生在ORDER BY子句對指定列進行排序之後,通過rowid回表查出SELECT子句需要的欄位資訊。
舉個例子,我們需要從充值記錄表篩選出2018年8月11日到12日的所有userid>140000使用者的訂單的明細,並按照金額從大到小進行排序(下面只是為filesort舉例,不是一種好的實現):
EXPLAIN
SELECT *
FROM order_detail
WHERE create_time >= '2018-08-11 00:00:00' and create_time < '2018-08-12 00:00:00' and userid > 140000
order by money desc;
+------+-------------+--------------+-------+--------------------+-------------+---------+------+------+-----------------------------+
| id | select_type | table| type| possible_keys| key | key_len | ref | rows | Extra |
+------+-------------+--------------+-------+--------------------+-------------+---------+------+------+-----------------------------+
| 1 | SIMPLE| order_detail | range | userid,create_time | create_time | 4 | NULL | 1 | Using where; Using filesort |
+------+-------------+--------------+-------+--------------------+-------------+---------+------+------+-----------------------------+
我們試著分析一下這個SQL的執行過程:
利用createtime索引,對滿足WHERE子句create****time >= ‘2018-08-11 00:00:00’ and create_time < ‘2018-08-12 00:00:00’的rowid進行回表(第一次回表),回表之後可以拿到該rowid對應的userid,若userid滿足userid > 140000的條件時,則將該行的rowid,money(ORDER BY的列)放入排序緩衝區。
若排序緩衝區能放下所有rowid, money對,則直接在排序緩衝區(記憶體)進行快排。
若排序緩衝區不能放下所有rowid, money對,則分塊快排,將塊存入臨時檔案(磁碟),再對塊進行歸併排序。
遍歷排序後的結果,對每一個rowid按照排序後的順序進行回表操作(第二次回表),取出SELECT子句需要的所有欄位。
熟悉計算機系統的人可以看出,第二次回表會表比第一次回表的效率低得多,因為第一次回表幾乎是順序I/O;而由於rowid是根據money進行排序的,第二次回表會按照rowid亂序去讀取行記錄,這些行記錄在磁碟中的儲存是分散的,每讀一行 磁碟都可能會產生定址時延(磁臂移動到指定磁軌)+旋轉時延(磁碟旋轉到指定扇區),這即是隨機I/O。
所以為了避免第二次回表的隨機I/O,MySQL在4.1之後做了一些改進:在第一次回表時就取出此次查詢用到的所有列,供後續使用。我們稱之為單次傳輸排序。
單次傳輸排序(MySQL4.1之後引入)
還是上面那條SQL,我們再看看單次傳輸排序的執行過程:
利用createtime索引,對滿足WHERE子句create****time >= ‘2018-08-11 00:00:00’ and create_time < ‘2018-08-12 00:00:00’的rowid進行回表(第一次回表),回表之後可以拿到改rowid對應的userid,若userid滿足userid > 140000的條件時,則將此次查詢用到該行的所有列(包括ORDER BY列)取出作為一個數據元組(tuple),放入排序緩衝區。
若排序緩衝區能放下所有tuples,則直接在排序緩衝區(記憶體)進行快排。
若排序緩衝區不能放下所有tuples,則分塊快排,將塊存入臨時檔案(磁碟),再對塊進行歸併排序。
遍歷排序後的每一個tuple,從tuple中取出SELECT子句需要所有欄位。
單次傳輸排序的弊端在於會將所有涉及到的列都放入排序緩衝區,排序緩衝區一次能放下的tuples更少了,進行歸併排序的概率增大。列資料量越大,需要的歸併路數更多,增加了額外的I/O開銷。所以列資料量太大時,單次傳輸排序的效率可能還不如兩次傳輸排序。
當然,列資料量太大的情況不是特別常見,所以MySQL的filesort會盡可能使用單次傳輸排序,但是為了防止上述情況發生,MySQL做了以下限制:
所有需要的列或ORDER BY的列只要是BLOB或者TEXT型別,則使用兩次傳輸排序。
所有需要的列和ORDER BY的列總大小超過maxlengthforsortdata位元組,則使用兩次傳輸排序。
我們開發者也應該儘可能讓filesort使用單次傳輸排序,不過EXPLAIN不會告訴我們這個資訊,所以我們只能肉眼檢查各列的大小看看是否會觸發上面兩個限制 導致兩次傳輸排序的發生。
5 補充說明
如第3小節所述,既然filesort的效率未必比索引掃描排序低,為什麼很多人會想避免filesort呢?
谷歌一下using filesort,幾乎都是”如何避免filesort”相關的內容:
這是因為通常ORDER BY子句會與LIMIT子句配合,只取出部分行。如果只是為了取出top1的行 卻對所有行進行排序,這顯然不是一種高效的做法。這種場景下 按順序取的索引掃描排序可能會比filesort擁有更好效能(當然也有例外)。
Whether the optimizer actually does so depends on whether reading the index is more efficient than a table scan if columns not in the index must also be read.
官方文件告訴我們optimizer會幫我們選擇一種高效的ORDER BY方式。
但也不能完全依賴optimizer的判斷,這時合理建立索引、引導它使用指定索引可能是更好的選擇。
6 參考資料
MySQL 8.0 Reference Manual :: 8.2.1.14 ORDER BY Optimization
《高效能MySQL》
Sergey Petrunia’s blog » How MySQL executes ORDER BY
MySQL filesort algorithms - Valinv
MySQL技術內幕:InnoDB儲存引擎(第2版)
B+ Tree Visualization
B+ Trees(pdf)
MySQL :: MySQL 8.0 Reference Manual :: 8.8.2 EXPLAIN Output Format
What do Clustered and Non clustered index actually mean? - Stack Overflow