和產品爭論MySQL底層如何實現order by的,慘敗!

點擊上方「JavaEdge」，關注公衆號
javascript

設爲「星標」，好文章不錯過！

這天風和日麗，小a正在工位上苦練摸魚技術，java

忽然接到產品的☎️，又來需求？ mysql

只聽到產品又開始口若黃河：我須要要查詢到city是「上海」的全部人的name，而且還要按name排序返回前1000人的name、age。程序員

小a急忙正襟危坐，從一堆庫表中翻出須要的表，抽出其建表語句：算法

看看錶結構，再看看產品的需求 sql

感受很容易，隨手SQL這麼一寫：性能優化

誒，這語句看着簡單而樸實，一個需求好像就完美解決了。但爲了顯示本身強大的性能優化水平，考慮到要避免全表掃描，因而又給 city 字段加索引。建完索引，天然還須要使用explain驗證一下：微信

explain select city, name, age from citizen where city = '上海' order by name limit 1000;+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+| 1 | SIMPLE | citizen | NULL | ALL | city | NULL | NULL | NULL | 32 | 100.00 | Using where; Using filesort |+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+1 row in set, 1 warning (0.00 sec)

Extra字段的 Using filesort 表示須要排序，MySQL會給每一個線程分配一塊內存用於排序，稱爲sort_buffer。session

這時魔鬼產品忽然湊過來問：給我看看你代碼咋寫的，你這麼寫你真的懂MySQL 底層怎麼執行order by的嗎？小a忽然驚醒，還真沒想過這些。架構

產品經理冷笑道：你知道你的 city 索引長啥樣嗎？我本身創建的，我咋可能不知道！隨手直接畫出

city字段的索引示意圖

產品，你可好好看了，這裏 id_x ~ id_(x+n) 的數據都知足city='上海’。

產品：那你卻是說說這條SQL的執行流程？不知道了吧，我來告訴你吧：

初始化sort_buffer，肯定放入name、city、age三字段
從索引city找到第一個知足city='上海’條件的主鍵id，即id_x；
到id主鍵索引取出整行，取name、city、age三個字段的值，存入sort_buffer
從索引city取下一個記錄的主鍵id
重複三、4，直到city的值不知足查詢條件，即主鍵id_y
對sort_buffer中數據按name作快排
取排序後結果的前1000行返回給客戶端

這就是全字段排序，執行流程以下：

按name排序 這一操做可能在內存中完成，也可能須要外部排序，而這就取決於

排序所需內存
參數sort_buffer_size MySQL爲排序開闢的內存（sort_buffer）的大小。若要排序的數據量小於sort_buffer_size，排序就在內存中完成。若排序數據量太大，內存放不下，則得利用磁盤臨時文件輔助排序。

產品又開始炫技了，又問到：你知道 一條排序語句什麼時候纔會使用臨時文件 嗎？這？這還真又觸及到個人知識盲區了！

mysql> SET optimizer_trace='enabled=on';Query OK, 0 rows affected (0.00 sec)
/* 使用 @a 保存 Innodb_rows_read 的初始值 */mysql> select VARIABLE_VALUE into @a from performance_schema.session_status where variable_name = 'Innodb_rows_read';Query OK, 1 row affected (0.00 sec)
mysql> select city, name,age from citizen where city='上海' order by name limit 1000;+--------+------+-----+| city | name | age |+--------+------+-----+| 上海 | java | 22 |...
/* 查看 OPTIMIZER_TRACE 輸出 */SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G
/* 使用 @b 保存 Innodb_rows_read 的當前值 */mysql> select VARIABLE_VALUE into @b from performance_schema.session_status where variable_name = 'Innodb_rows_read';Query OK, 1 row affected (0.00 sec)
/* 計算 Innodb_rows_read 的差值 */mysql> select @b-@a;

查看 OPTIMIZER_TRACE 結果中的 number_of_tmp_files 字段確認是否使用臨時文件。

"filesort_execution": [],"filesort_summary": { "rows": 4000 "examined_rows": 4000, "number_of_tmp_files": 12, "sort_buffer_size": 32664 , "sort_mode": "<sort_key, packed_additional_fields>"

number_of_tmp_files 排序過程當中使用的臨時文件數。爲啥須要12個文件？內存放不下時，就須要使用外部排序，外部排序通常使用歸併排序。MySQL將須要排序的數據分紅12份，每一份單獨排序後存在這些臨時文件中。而後把這12個有序文件再合併成一個有序的大文件。

若 sort_buffer_size 超過需排序的數據量大小，則 number_of_tmp_files 就是0，即排序可直接在內存完成。

不然就須要放在臨時文件中排序。sort_buffer_size越小，須要分紅的份數越多，number_of_tmp_files的值就越大。

examined_rows 參與排序的行數。測試表有4000條知足city='上海’的記錄，因此該參數爲4000。
sort_mode 的packed_additional_fields 排序過程對字符串作了「緊湊」處理。即便name字段的定義是varchar(16)，在排序過程當中仍是要按實際長度分配空間。

select @b-@a 的結果4000，即整個執行過程只掃描了4000行。

注意，爲了不對結論形成干擾，我把internal_tmp_disk_storage_engine設置成MyISAM。不然，select @b-@a的結果會顯示爲4001。由於查詢OPTIMIZER_TRACE表時，須要用到臨時表，而internal_tmp_disk_storage_engine的默認值是InnoDB。若使用InnoDB，把數據從臨時表取出時，會讓Innodb_rows_read的值加1。

我驚奇地望着產品，像瞻仰偉人通常，不如你繼承個人代碼吧，讓我來作產品？

rowid排序 上面的算法，只是對原表數據讀了一遍，剩下的操做都是在sort_buffer和臨時文件中執行。但這就存在問題：若查詢要返回的字段不少，那麼sort_buffer要放的字段數就會不少，內存裏可以同時放下的行數就會變少，就要分紅不少臨時文件，排序性能就會不好。 因此若單行很大，該方法的效率可不夠行哦。

產品大大又開始發難，那麼你知道若MySQL認爲排序的單行長度太大，它又會幹啥嗎？

如今修改個參數，讓MySQL採用另一種算法。

SET max_length_for_sort_data = 16;

max_length_for_sort_data MySQL用於控制用於排序的行數據的長度。若單行的長度超過該值，MySQL就認爲單行太大，要換個算法。

city、name、age 三字段的定義總長度36，那你看我把max_length_for_sort_data設爲16會咋樣。

新的算法放入sort_buffer的字段，只有要排序的列（即name字段）和主鍵id。但這時，排序的結果就因少了city和age字段值，不能直接返回了，整個執行流程變成以下：

初始化sort_buffer，肯定放入兩個字段，即name和id
從city找到第一個知足city='上海’條件的主鍵id，也就是圖中的id_x
到id取出整行，取name、id這兩個字段，存入sort_buffer
從city取下一個記錄的主鍵id
重複步驟三、4直到不知足city='上海’，也就是圖中的id_y
對sort_buffer中的數據按照字段name進行排序
遍歷排序結果，取前1000行，並按照id的值回到原表中取出city、name和age三個字段返回給客戶端。

聽到這裏，感受明白了一些：產品你別急，你看我畫下這個rowid排序執行過程的示意圖，看看對不對？

你看這個和你以前畫的全字段排序示意圖，其實就是多訪問了一次表citizen的主鍵索引，即step7。

注意了，最後的resultSet是一個邏輯概念，實際上MySQL服務端從排序後的sort_buffer中依次取出id，而後到原表查到city、name和age這三字段的結果，不須要在服務端再耗費內存存儲結果，而是直接返回給客戶端。

這時查看rowid排序的OPTIMIZER_TRACE結果，看看和以前的不一樣之處在哪裏

"filesort_execution": [],"filesort_summary": { "rows": 4000 "examined_rows": 4000, "number_of_tmp_files": 10, "sort_buffer_size": 32728 , "sort_mode": "<sort_key, rowid>"

select @b-@a結果變成5000 由於這時除了排序過程，在排序完成後，還要根據id去原表取值。因爲語句是limit 1000，所以會多讀1000行。
sort_mode 變成了 <sort_key, rowid> 表示參與排序的只有name和id字段
number_of_tmp_files 變成10 由於這時參與排序的行數雖然仍是4000，但每行都變小了，所以需排序的總數據量就小了，須要的臨時文件也就少咯。

產品最後總結到：

若MySQL認爲排序內存過小，會影響排序效率，就會採用rowid排序這樣排序過程當中一次能夠排序更多行，但最後須要回表取數據
若MySQL認爲內存夠大，會優先選擇全字段排序把須要字段都放到sort_buffer，這樣排序後就直接從內存返回查詢結果，不用回表。

因此MySQL就是：若內存夠，就多利用內存，儘可能減小磁盤訪問。

對InnoDB，rowid排序會要求回表，多形成了磁盤讀，所以不會被優先選擇。因此MySQL排序是個高成本操做。

是否是全部order by都需排序呢？若不排序就能獲得正確的結果，那對系統的消耗會小不少，語句的執行時間也會變得更短。

並不是全部order by都需排序操做。MySQL之因此須要生成臨時表，而且在臨時表上作排序，是由於原來的數據都是無序的。

若是能保證從city索引上取出來的行，天生就是按name遞增排序，是否是就能夠不用再排序了？是的。

因此能夠建立一個city,name聯合索引：

alter table t add index citizen(city, name);

該索引的示意圖依然能夠用樹搜索定位到第一個知足city='上海’的記錄，而且能確保接下來按順序取「下一條記錄」的遍歷過程，只要city是上海，name值必定有序。這樣整個查詢過程的流程就變成：

從索引(city,name)找到第一個知足city='上海’條件的主鍵id
到主鍵id索引取出整行，取name、city、age三個字段的值，做爲結果集的一部分直接返回
從索引(city,name)取下一個記錄主鍵id
重複步驟二、3，直到查到第1000條記錄，或者是不知足city='上海’條件時循環結束

引入(city,name)聯合索引後，查詢語句的執行計劃

可見，該查詢過程無需臨時表，也無需排序。

使用 explain 查看(city,name)聯合索引，查詢語句的執行計劃

 explain select city, name, age from citizen where city = '上海' order by name limit 1000;+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+| 1 | SIMPLE | citizen | NULL | ref | city,name | name | 51 | const | 4000 | 100.00 | Using index condition |+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+1 row in set, 1 warning (0.00 sec)

可見Extra字段中沒有Using filesort了，也就是不須要排序了。並且因爲(city,name)這個聯合索引自己有序，因此該查詢也不用把4000行全都讀一遍，只要找到知足條件的前1000條記錄便可退出。在這個例子裏，只需掃描1000次。

該語句的執行流程有沒有可能進一步簡化呢？

覆蓋索引索引上的信息足夠知足查詢請求，不須要再回到主鍵索引上去取數據。

按覆蓋索引，能夠再優化一下這個查詢語句的執行流程。針對這個查詢，咱們能夠建立一個city、name和age的聯合索引，對應的SQL語句就是：

alter table t add index city_user_age(city, name, age);

這時，對於city字段的值相同的行來講，仍是按照name字段的值遞增排序的，此時的查詢語句也就再也不須要排序了。這樣整個查詢語句的執行流程就變成了：

從索引(city,name,age)找到第一個知足city='上海’條件的記錄，取出其中的city、name和age這三個字段的值，做爲結果集的一部分直接返回
從索引(city,name,age)取下一個記錄，一樣取出這三個字段的值，做爲結果集的一部分直接返回
重複2，直到查到第1000條記錄或不知足city='上海'

引入 (city,name,age) 聯合索引，查詢語句的執行流程

explain查看(city,name,age)聯合索引查詢語句的執行計劃

explain select city, name, age from citizen where city = '上海' order by name limit 1000;+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+| 1 | SIMPLE | citizen | NULL | ref | city,name,age | age | 51 | const | 4000 | 100.00 | Using where; Using index |+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+1 row in set, 1 warning (0.00 sec)

Extra字段裏面多了「Using index」，說明使用了覆蓋索引，性能上會快不少。但這並不是說要爲了每一個查詢能用上覆蓋索引，就要把語句中涉及的字段都建上聯合索引，畢竟索引也很佔空間，並且修改新增都會致使索引改變，仍是具體業務場景具體分析。

參考

「order by」是怎麼工做的？

https://blog.csdn.net/Linuxhus/article/details/112672434?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_title-0&spm=1001.2101.3001.4242

每天寫order by，你知道Mysql底層執行原理嗎？

往期推薦

因爲不知線程池的bug,某Java程序員叕被祭天

程序員因重複記錄日誌撐爆ELK被辭退!

擁抱Kubernetes,再見了Spring Cloud

JDK爲什麼本身先破壞雙親委派模型?

目前交流羣已有 800+人，旨在促進技術交流，可關注公衆號添加筆者微信邀請進羣

喜歡文章，點個「在看、點贊、分享」素質三連支持一下~

本文分享自微信公衆號 - JavaEdge（Java-Edge）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。