2. 程式人生 > >MySQL之ORDER BY 詳細解析

MySQL之ORDER BY 詳細解析

阿新 • • 發佈：2019-01-04

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：

  1. SELECT *

  2. FROM userinfo

  3. ORDER BY userid;

MySQL會直接遍歷上圖userid索引的葉子節點連結串列，不需要進行額外的排序操作。這就是用索引掃描來排序。

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

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

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

介紹索引掃描排序之前，先看看索引的用途

SQL語句中，WHERE

子句和ORDER BY子句都可以使用索引：WHERE子句使用索引避免全表掃描，ORDER BY子句使用索引避免filesort（用“避免”可能有些欠妥，某些場景下全表掃描、filesort未必比走索引慢），以提高查詢效率。

雖然索引能提高查詢效率，但在一條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：

  1. CREATE TABLE `order_detail` (

  2. `id` int(11) NOT NULL AUTO_INCREMENT,

  3. `userid` int(11) NOT NULL,

  4. `money` float NOT NULL,

  5. `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

  6. PRIMARY KEY (`id`),

  7. KEY `userid` (`userid`),

  8. KEY `create_time` (`create_time`)

  9. ) ENGINE=InnoDB DEFAULT CHARSET=utf8

寫指令碼插入100w行資料（InnoDB別用COUNT(*)查總行數，會掃全表，這裡只是為了演示）：

  1. SELECT COUNT(*) FROM order_detail;

  2. +----------+

  3. | COUNT(*) |

  4. +----------+

  5. | 1000000 |

  6. +----------+

  7. SELECT * FROM order_detail LIMIT 5;

  8. +----+--------+-------+---------------------+

  9. | id | userid | money | create_time |

  10. +----+--------+-------+---------------------+

  11. | 1 | 104832 | 3109 | 2013-01-01 07:40:38 |

  12. | 2 | 138455 | 6123 | 2013-01-01 07:40:42 |

  13. | 3 | 109967 | 7925 | 2013-01-01 07:40:46 |

  14. | 4 | 166686 | 4307 | 2013-01-01 07:40:55 |

  15. | 5 | 119837 | 1912 | 2013-01-01 07:40:58 |

  16. +----+--------+-------+---------------------+

現在我們想取出userid=104832使用者的所有充值記錄，並按照充值時間create_time正序返回。

場景一 索引只用於WHERE子句

寫出如下SQL並EXPLAIN一下：

  1. EXPLAIN

  2. SELECT *

  3. FROM order_detail

  4. WHERE userid = 104832

  5. ORDER BY create_time;

  6. +------+-------------+--------------+------+---------------+--------+---------+-------+------+-----------------------------+

  7. | id | select_type | table| type | possible_keys | key| key_len | ref | rows | Extra |

  8. +------+-------------+--------------+------+---------------+--------+---------+-------+------+-----------------------------+

  9. | 1 | SIMPLE| order_detail | ref | userid| userid | 4 | const | 8 | Using where; Using filesort |

  10. +------+-------------+--------------+------+---------------+--------+---------+-------+------+-----------------------------+

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：

  1. EXPLAIN

  2. SELECT *

  3. FROM order_detail

  4. FORCE INDEX (create_time)

  5. WHERE userid = 104832

  6. ORDER BY create_time;

  7. +------+-------------+--------------+-------+---------------+-------------+---------+------+--------+-------------+

  8. | id | select_type | table| type| possible_keys | key | key_len | ref | rows | Extra |

  9. +------+-------------+--------------+-------+---------------+-------------+---------+------+--------+-------------+

  10. | 1 | SIMPLE| order_detail | index | NULL| create_time | 4 | NULL | 998056 | Using where |

  11. +------+-------------+--------------+-------+---------------+-------------+---------+------+--------+-------------+

可以看到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舉例，不是一種好的實現）：

  1. EXPLAIN

  2. SELECT *

  3. FROM order_detail

  4. WHERE create_time >= '2018-08-11 00:00:00' and create_time < '2018-08-12 00:00:00' and userid > 140000

  5. order by money desc;

  6. +------+-------------+--------------+-------+--------------------+-------------+---------+------+------+-----------------------------+

  7. | id | select_type | table| type| possible_keys| key | key_len | ref | rows | Extra |

  8. +------+-------------+--------------+-------+--------------------+-------------+---------+------+------+-----------------------------+

  9. | 1 | SIMPLE| order_detail | range | userid,create_time | create_time | 4 | NULL | 1 | Using where; Using filesort |

  10. +------+-------------+--------------+-------+--------------------+-------------+---------+------+------+-----------------------------+

我們試著分析一下這個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

原文地址

相關推薦

MySQL之ORDER BY 詳細解析

1 概述 MySQL有兩種方式可以實現ORDER BY： 1.通過索引掃描生成有序的結果 2.使用檔案排序(filesort) 圍繞著這兩種排序方式，我們試著理解一下ORDER BY的執行過程以及回答一些常見的問題（下文僅討論InnoDB儲存引擎）。

mysql之 binlog維護詳細解析（開啟、binlog相關引數作用、mysqlbinlog解讀、binlog刪除）

binary log 作用：主要實現三個重要的功能：用於複製，用於恢復，用於審計。 binary log 相關引數： log_bin 設定此引數表示啟用binlog功能，並指定路徑名稱 log_bin_index 設定此引數是指定二進位制索引檔案的路徑與名稱 binlog_

Mysql之group by 和order by 一起用時的排序問題

業務需求，需要查詢表裡不同分類下的order最大的記錄。 查看錶中的記錄： SELECT id,tid,`order`, FROM_UNIXTIME(yestime) FROM tfen WHERE tid IN(7512, 7514) ORDER BY `order` DESC ;

讓天下沒有難用的資料庫 » MySql sql優化之order by desc/asc limit M

Order by desc/asc limit M是我在mysql sql優化中經常遇到的一種場景，其優化原理也非常的簡單，就是利用索引的有序性，優化器沿著索引的順序掃描，在掃描到符合條件的M行資料後，停止掃描；看起來非常的簡單，但是我經常看到很多效能較差的sql沒有利用這個優化規律，下面將結合一些

MySQL查詢優化之order by的優化

原文地址：https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html 譯文： 8.2.1.14 ORDER BY 優化 本節描述MySQL何時可以使用索引來滿足order by子句，不能使用索引時使用的檔

mysql中order by和group by的詳細區別是詳細區別

order by 排序查詢、asc升序、desc降序示例：select * from 學生表 order by 年齡 查詢學生表資訊、按年齡的升序(預設、可預設、從低到高)排列顯示也可以多條件排序、 比如 order by 年齡,成績 desc 按年齡升序排列後

【MySQL】效能優化之 order by (一)

前言    工作過程中,各種業務需求在訪問資料庫的時候要求有order by排序。有時候不必要的或者不合理的排序操作很可能導致資料庫系統崩潰。如何處理好order by排序呢？本文從原理以及優化層面介紹 order by 。一 MySQL中order by的原理   1 利用索引的有序性獲取有序資料  當查詢

玩得一手好註入之order by排序篇

布爾 idt center 取反 操作符 aaa 發生 9.png 很多 看了之前Gr36_前輩在先知上的議題，其中有提到排序註入，這個在最近經常遇到這樣的問題，所以先總結下order by 排序註入的知識。 0×0

MySQL優化order by導致的 using filesort

from 永久 idc SM 大於 xid 圖片 sele style using filesort 一般出現在 使用了 order by 語句當中。using filesort不一定引起mysql的性能問題。但是如果查詢次數非常多，那麽每次在mysql中進行排序，還是會有

【MySql】Order By 排序

des 需要 .com utf 字符集 條件 itl sele com 你可以使用任何字段來作為排序的條件，從而返回排序後的查詢結果。 你可以設定多個字段來排序。 你可以使用 ASC 或 DESC 關鍵字來設置查詢結果是按升序或降序排列。 默認情況下，它是按升序排列。 你

mysql 使用order by

word sql str1 log http esc ... comment value 1、mysql 使用order by field() 自定義排序 order by field(value,str1,str2,str3,str4......strn) 例如：sele

MySQL之——GROUP BY分組取欄位最大值

出處：http://blog.csdn.net/l1028386804/article/details/54657412 假設有一個業務場景，需要查詢使用者登入記錄資訊，其中表結構如下： [sql]  view plain  cop

17.MySQL優化ORDER BY 優化

介紹 本節描述MySQL何時可以使用索引來滿足ORDER BY子句，無法使用索引時使用的filesort操作，和優化器提供的有關ORDER BY的執行計劃資訊。 一個ORDER BY有和沒有 LIMIT可能以不同的順序返回行： 使用索引來優化ORDER BY 使用f

MYSQL "ORDER BY rand()"的坑--容易導致機器負載、CPU佔用過高

在一次微信砍價活動營銷中，使用了4核16G10M頻寬的伺服器支撐業務，本來這個配置跑個PHP+MYSQL+nginx肯定輕輕鬆的事情，可是隨著活動的高潮，併發數一高，機器負載核CPU一下子就達到100% 始終找不到原因，只知道是mysql分配的記憶體不夠，一直給它加，但是重啟m

MySQL單表查詢詳細解析

一、關鍵字的執行優先順序 　　1，from：找到表 　　2，where：拿著where指定的約束條件，去檔案/表中取出一條條資料 　　3，group by：將取出的一條條資料進行分組，如果沒有group by，則整體作為一組 　　4，having：將分組的結果進行having過濾 　　5，selec

Mysql 【order by 不唯一欄位】與【limit】混用的坑

背景： 分頁查詢排序後的資料，是一個非常常見的業務場景；但當使用不唯一的欄位排序時，分兩頁查詢的資料可能出現同一條資料，並丟失資料！ 示例： 同樣的查詢條件，offset不同，竟然取到了同一條

Android技能樹 — 網路小結(7)之 Retrofit原始碼詳細解析

前言： 哈哈，其實寫的還是很水，各位原諒我O(∩_∩)O。 介於自己的網路方面知識爛的一塌糊塗，所以準備寫相關網路的文章，但是考慮全部寫在一篇太長了，所以分開寫，希望大家能仔細看，最好可以指出我的錯誤，讓我也能糾正。 1.講解相關的整個網路體系結構： Android技能樹 — 網路小結(1)之網路體系

mysql 使用order by field() 自定義排序

 一、mysql field自定義排序函式的格式 order by field(value,str1,str2,str3,str4,,,,,,strn) 其中value後面的引數自定義，不限制引數個數 含義 將獲取出來的資料根據str1,str2,str3,str4

mysql的order by排序不正確的問題

那是因為order by 後的欄位的值是一樣的，需要再新加一個欄位來區分排序。 例如，兩個同學的分數都是88分，按分數降序排列，則 select * from student order by score DESC，但是每次查詢，排序結果可能不一樣，需要再加一個欄位來排序

mysql中order by 指定排序

原 mysql中order by 可以指定排序 2017年05月19日 17:01:26 qq_36340642 閱讀數：27528 這裡