點擊上方“JavaEdge”，關注公衆號
這天風和日麗，小a正在工位上苦練摸魚技術，
突然接到產品的☎️，又來需求？ 
只聽到產品又開始口若黃河：我需要要查詢到city是“上海”的所有人的name，並且還要按name排序返回前1000人的name、age。
小a急忙正襟危坐，從一堆庫表中翻出需要的表，抽出其建表語句： 
看看錶結構，再看看產品的需求 
感覺很容易，隨手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。
這時魔鬼產品突然湊過來問：給我看看你代碼咋寫的，你這麼寫你真的懂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
重複3、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重複步驟3、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
重複步驟2、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底層執行原理嗎？
往期推薦
目前交流羣已有 800+人，旨在促進技術交流，可關注公衆號添加筆者微信邀請進羣
喜歡文章，點個“在看、點贊、分享”素質三連支持一下~
本文分享自微信公衆號 - JavaEdge（Java-Edge）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。