Mysql - ORDER BY詳解

時間 2019-11-07

標籤 mysql order 詳解欄目 MySQL 简体版

原文原文鏈接

0 索引

1 概述

2 索引掃描排序和文件排序簡介

3 索引掃描排序執行過程分析

4 文件排序

5 補充說明

6 參考資料

1 概述

MySQL有兩種方式能夠實現ORDER BY：html

1.經過索引掃描生成有序的結果
2.使用文件排序(filesort)

圍繞着這兩種排序方式，咱們試着理解一下ORDER BY的執行過程以及回答一些常見的問題。（下文僅討論InnoDB存儲引擎）mysql

2 索引掃描排序和文件排序(filesort)簡介

咱們知道InnoDB存儲引擎以B+樹做爲索引的底層實現，B+樹的葉子節點存儲着全部數據頁而內部節點不存放數據信息，而且全部葉子節點造成一個(雙向)鏈表。
舉個例子，假設userinfo表的userid字段上有主鍵索引，且userid目前的範圍在1001~1006之間，則userid的索引B+樹以下：(這裏只是爲了舉例，下圖忽略了InnoDB數據頁默認大小16KB、雙向鏈表，而且假設B+樹度數爲三、userid順序插入)
sql

如今咱們想按照userid從小到大的順序取出全部用戶信息，執行如下SQL性能

SELECT * 
  FROM userinfo
    ORDER BY userid;

MySQL會直接遍歷上圖userid索引的葉子節點鏈表，不須要進行額外的排序操做。這就是用索引掃描來排序。spa

但若是userid字段上沒有任何索引，圖1的B+樹結構不存在，MySQL就只能先掃表篩選出符合條件的數據，再將篩選結果根據userid排序。這個排序過程就是filesort。.net

下文將詳細介紹這兩種排序方式。設計

3 索引掃描排序執行過程分析

介紹索引掃描排序以前，先看看索引的用途
SQL語句中，WHERE子句和ORDER BY子句均可以使用索引：WHERE子句使用索引避免全表掃描，ORDER BY子句使用索引避免filesort（用「避免」可能有些欠妥，某些場景下全表掃描、filesort未必比走索引慢），以提升查詢效率。
雖然索引能提升查詢效率，但在一條SQL裏，對於一張表的查詢一次只能使用一個索引（注：排除發生index merge的可能性），也就是說當WHERE子句與ORDER BY子句要使用的索引不一致時，MySQL只能使用其中一個索引(B+樹)。code

也就是說，一個既有WHERE又有ORDER BY的SQL中，使用索引有三個可能的場景:orm

只用於WHERE子句篩選出知足條件的數據
只用於ORDER BY子句返回排序後的結果
既用於WHERE又用於ORDER BY，篩選出知足條件的數據並返回排序後的結果

舉個例子，咱們建立一張order_detail表記錄每一筆充值記錄的userid(用戶id)、money(充值金額)、create_time(充值時間)，主鍵是自增id：htm

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的執行過程：

利用create_time索引，對知足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，咱們再看看單次傳輸排序的執行過程：

利用create_time索引，對知足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的列總大小超過max_length_for_sort_data字節，則使用兩次傳輸排序。

咱們開發者也應該儘量讓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的判斷，這時合理創建索引、引導它使用指定索引多是更好的選擇。