MySQL排序原理與MySQL5.6案例分析【轉】

時間 2019-12-16

原文原文鏈接

本文來自：http://www.cnblogs.com/cchust/p/5304594.html，其中對於本身以爲是重點的加了標記，方便本身查閱。更多詳細的說明能夠看沃趣科技的文章說明。
html

前言
排序是數據庫中的一個基本功能，MySQL也不例外。用戶經過Order by語句即能達到將指定的結果集排序的目的，其實不只僅是Order by語句，Group by語句，Distinct語句都會隱含使用排序。本文首先會簡單介紹SQL如何利用索引避免排序代價，而後會介紹MySQL實現排序的內部原理，並介紹與排序相關的參數，最後會給出幾個「奇怪」排序例子，來談談排序一致性問題，並說明產生現象的本質緣由。mysql

1.排序優化與索引使用
爲了優化SQL語句的排序性能，最好的狀況是避免排序，合理利用索引是一個不錯的方法。由於索引自己也是有序的，若是在須要排序的字段上面創建了合適的索引，那麼就能夠跳過排序的過程，提升SQL的查詢速度。下面我經過一些典型的SQL來講明哪些SQL能夠利用索引減小排序，哪些SQL不能。假設t1表存在索引key1(key_part1,key_part2),key2(key2)算法

a.能夠利用索引避免排序的SQLsql

 
    
     
       
       
         SELECT  
         *  
         FROM  
         t1  
         ORDER  
         BY  
         key_part1,key_part2; 
        
 
         SELECT  
         *  
         FROM  
         t1  
         WHERE  
         key_part1 = constant  
         ORDER  
         BY  
         key_part2; 
        
 
         SELECT  
         *  
         FROM  
         t1  
         WHERE  
         key_part1 > constant  
         ORDER  
         BY  
         key_part1  
         ASC 
         ; 
        
 
         SELECT  
         *  
         FROM  
         t1  
         WHERE  
         key_part1 = constant1  
         AND  
         key_part2 > constant2  
         ORDER  
         BY  
         key_part2; 
        
 
     
 
    
  

b.不能利用索引避免排序的SQL數據庫

 
         //排序字段在多個索引中，沒法使用索引排序 
        
         SELECT  
         *  
         FROM  
         t1  
         ORDER  
         BY  
         key_part1,key_part2, key2; 
        
         //排序鍵順序與索引中列順序不一致，沒法使用索引排序 
        
         SELECT  
         *  
         FROM  
         t1  
         ORDER  
         BY  
         key_part2, key_part1; 
        
         //升降序不一致，沒法使用索引排序 
        
         SELECT  
         *  
         FROM  
         t1  
         ORDER  
         BY  
         key_part1  
         DESC 
         , key_part2  
         ASC 
         ; 
        
         //key_part1是範圍查詢，key_part2沒法使用索引排序 
        
         SELECT  
         *  
         FROM  
         t1  
         WHERE  
         key_part1> constant  
         ORDER  
         BY  
         key_part2;

2.排序實現的算法
對於不能利用索引避免排序的SQL，數據庫不得不本身實現排序功能以知足用戶需求，此時SQL的執行計劃中會出現「Using filesort」，這裏須要注意的是filesort並不意味着就是文件排序，其實也有多是內存排序，這個主要由sort_buffer_size參數與結果集大小肯定。MySQL內部實現排序主要有3種方式，常規排序，優化排序和優先隊列排序，主要涉及3種排序算法：快速排序、歸併排序和堆排序。緩存

假設表結構和SQL語句以下：性能

CREATE TABLE t1(id int, col1 varchar(64), col2 varchar(64), col3 varchar(64), PRIMARY KEY(id),key(col1,col2));
SELECT col1,col2,col3 FROM t1 WHERE col1>100 ORDER BY col2;

a.常規排序，雙路排序
(1).從表t1中獲取知足WHERE條件的記錄
(2).對於每條記錄，將記錄的主鍵+排序鍵(id,col2)取出放入sort buffer
(3).若是sort buffer能夠存放全部知足條件的(id,col2)對，則進行排序；不然sort buffer滿後，進行排序並寫到臨時文件中。(排序算法採用的是快速排序算法)
(4).若排序中產生了臨時文件，須要利用歸併排序算法，保證臨時文件中記錄是有序的
(5).循環執行上述過程，直到全部知足條件的記錄所有參與排序
(6).掃描排好序的(id,col2)隊，即sort buffer，並利用主鍵id去取SELECT須要返回的其餘列(col1,col2,col3)
(7).將獲取的結果集返回給用戶。
從上述流程來看，是否使用文件排序主要看sort buffer是否能容下須要排序的(id,col2)的結果集，這個buffer的大小由sort_buffer_size參數控制。此外一次排序還須要兩次IO，一次是取排序字段(id,col2)到sort buffer中，第二次是經過上面取出的主鍵id再來取其餘所須要返回列(col1,col2,col3)，因爲返回的結果集是按col2排序，所以id是亂序的，經過亂序的id取(col1,col2,col3)時會產生大量的隨機IO。對於第二次IO取MySQL自己會優化，即在取以前先將主鍵id排序，並放入緩衝區，這個緩存區大小由參數read_rnd_buffer_size控制，而後有序去取記錄，將隨機IO轉爲順序IO。
b.優化排序，單路排序，max_length_for_sort_data
常規排序方式除了排序自己，還須要額外兩次IO。優化排序方式相對於常規排序，減小了第二次IO。主要區別在於，一次性取出sql中出現的全部字段放入sort buffer中而不是隻取排序須要的字段(id,col2)。因爲sort buffer中包含了查詢須要的全部字段，所以排序完成後能夠直接返回，無需二次取數據。這種方式的代價在於，一樣大小的sort buffer，能存放的(col1,col2,col3)數目要小於(id,col2)，若是sort buffer不夠大，可能致使須要寫臨時文件，形成額外的IO。固然MySQL提供了參數max_length_for_sort_data，只有當排序sql裏出現的全部字段小於max_length_for_sort_data時，才能利用優化排序方式，不然只能用常規排序方式。
c.優先隊列排序
爲了獲得最終的排序結果，咱們都須要將全部知足條件的記錄進行排序才能返回。那麼相對於優化排序方式，是否還有優化空間呢？5.6版本針對Order by limit M，N語句，在空間層面作了優化，加入了一種新的排序方式--優先隊列，這種方式採用堆排序實現。堆排序算法特徵正好能夠解limit M,N 這類排序的問題，雖然仍然須要全部字段參與排序，可是只須要M+N個元組的sort buffer空間便可，對於M，N很小的場景，基本不會由於sort buffer不夠而致使須要臨時文件進行歸併排序的問題。對於升序，採用大頂堆，最終堆中的元素組成了最小的N個元素，對於降序，採用小頂堆，最終堆中的元素組成了最大的N的元素。測試

3.排序不一致問題優化

案例1：order by no_index limit n在MySQL5.5和5.6中的不一致spa

MySQL從5.5遷移到5.6之後，發現分頁出現了重複值（排序字段沒有用索引，或則直接是全表掃描），MariaDB已是優化後的方案，和5.6一致。

問題源頭：https://bbs.aliyun.com/read/248026.html，解決辦法：http://mysql.taobao.org/monthly/2015/06/04/

測試表與數據：

create table t1(id int primary key, c1 int, c2 varchar(128));
insert into t1 values(1,1,'a');
insert into t1 values(2,2,'b');
insert into t1 values(3,2,'c');
insert into t1 values(4,2,'d');
insert into t1 values(5,3,'e');
insert into t1 values(6,4,'f');
insert into t1 values(7,5,'g');

假設每頁3條記錄，第一頁limit 0,3和第二頁limit 3,3查詢結果以下：

咱們能夠看到 id爲4的這條記錄竟然同時出如今兩次查詢中，這明顯是不符合預期的，並且在5.5版本中沒有這個問題。

使用優先隊列排序的目的就是在不能使用索引有序性的時候，若是要排序，而且使用了limit n，那麼只須要在排序的過程當中，保留n條記錄便可，這樣雖然不能解決全部記錄都須要排序的開銷，可是隻須要 sort buffer 少許的內存就能夠完成排序，上面已經說明。

之因此MySQL5.6出現了第二頁數據重複的問題，是由於使用了優先隊列排序，其使用了堆排序的排序方法，而堆排序是一個不穩定的排序方法，也就是相同的值（例子中的值2）可能排序出來的數據和讀出來的數據順序不一致，沒法保證排序先後數據位置的一致，因此致使分頁重複的現象。

爲了不這個問題，有幾種方法：

①：索引排序字段

利用索引的有序性，在字段添加上索引，就直接按照索引的有序性進行讀取並分頁，從而能夠規避遇到的這個問題。

②：利用多列索引，對於單列相同沒法排序的，利用其主鍵進行排序：

select * from t1 order by c1,id asc limit 0,3;
select * from t1 order by c1,id asc limit 3,3;

案例2：單路排序和雙路排序返回結果不同

兩個相似的查詢語句，除了返回列不一樣，其它都相同，但排序的結果不一致。

測試表與數據：

create table t2(id int primary key, status int, c1 varchar(255),c2 varchar(255),c3 varchar(255),key(c1));
insert into t2 values(7,1,'a',repeat('a',255),repeat('a',255));
insert into t2 values(6,2,'b',repeat('a',255),repeat('a',255));
insert into t2 values(5,2,'c',repeat('a',255),repeat('a',255));
insert into t2 values(4,2,'a',repeat('a',255),repeat('a',255));
insert into t2 values(3,3,'b',repeat('a',255),repeat('a',255));
insert into t2 values(2,4,'c',repeat('a',255),repeat('a',255));
insert into t2 values(1,5,'a',repeat('a',255),repeat('a',255));

分別執行SQL語句：

select id,status,c1,c2 from t2 force index(c1) where c1>='b' order by status;
select id,status from t2 force index(c1) where c1>='b' order by status;

執行結果以下：

看看二者的執行計劃是否相同

爲了說明問題，由於測試數據很少，確保能走上c1列索引，加了force index的hint。語句經過c1列索引取id，而後去表中撈取返回的列。根據c1列值的大小，記錄在c1索引中的相對位置以下：

(c1,id)<===>(b,6),(b,3),(c,5),(c,2)，

對應的status值分別爲2,3,2,4。從表中取數據並按status排序，則相對位置變爲(6,2,b),(5,2,c),(3,3,b),(2,4,c)，這就是第二條語句查詢返回的結果，那麼爲何第一條查詢語句(6,2,b),(5,2,c)是調換順序的呢？

這裏說明下：
1. Query 語句所取出的字段類型大小總和小於max_length_for_sort_data 。
2. 排序的字段不包含TEXT和BLOB類型。

以前提到的優化排序就能夠明白了：因爲第一條查詢返回的列的字節數超過了max_length_for_sort_data，致使排序採用常規排序，而在這種狀況下第二次IO時，MYSQL自己優化會對id排序，將隨機IO轉爲順序IO，因此返回的先是5，後是6；而第二條查詢採用的是優化排序，沒有第二次取數據的過程，保持了排序後記錄的相對位置，直接在sort buffer裏取出。對於第一條語句，若想採用優化排序，咱們將max_length_for_sort_data設置調大便可，好比2048。

4.參考文檔

http://dev.mysql.com/doc/refman/5.6/en/order-by-optimization.html

http://mysql.taobao.org/monthly/2015/06/04/

http://ifxoxo.com/mysql_order_by.html