MySQL分頁優化中的「INNER JOIN方式優化分頁算法」到底在什麼狀況下會生效？

 

本文出處：http://www.cnblogs.com/wy123/p/7003157.html 

 

最近無心間看到一個MySQL分頁優化的測試案例，並無很是具體地說明測試場景的狀況下，給出了一種經典的方案，
由於現實中不少狀況都不是固定不變的，能總結出來通用性的作法或者說是規律，是要考慮很是多的場景的，
同時，面對可以達到優化的方式要追究其緣由，一樣的作法，換了個場景，達不到優化效果的，還要追究其緣由。
我的對此場景在不用狀況表示懷疑，而後本身測試了一把，果真發現一些問題，同時也證明了一些預期的想法。
本文就MySQL分頁優化，從最最簡單的狀況出發，來作一個簡單的分析。

另：本文測試環境是最最低配置的雲服務器，相對來講服務器硬件環境有限，不過對於不一樣的語句（寫法）應該是「平等的」

20170916補充:
　　想一想用腳趾頭就能明白，
　　1，若是分頁排序字段是彙集索引，徹底不必對索引分頁再查詢數據，由於索引就是數據自己。
　　2，若是是非彙集索引，先對索引分頁，而後再利用索引去查詢數據，先分頁索引確實能夠減小掃描的範圍
　　3，若是常常按照2中的方式查詢，也就是按照非彙集索引排序查詢，那麼爲何不在該列上創建彙集索引呢。

 

 

MySQL經典的分頁「優化」作法

MySQL分頁優化中，有一種經典的問題，在查詢越「靠後」的數據越慢（取決於表上的索引類型，對於B樹結構的索引，SQL Server中也同樣）
select * from t order by id limit m,n。
也即隨着M的增大，查詢一樣多的數據，會愈來愈慢
面對這一問題，因而就產生了一種經典的作法，相似於（或者變種）以下的寫法
就是先把分頁範圍內的id單獨找出來，而後再跟基表作關聯，最後查詢出來所須要的數據
select * from t
inner join (select id from t order by id limit m,n)t1 on t1.id = t.id

這種作法是否是老是生效的，或者說是在什麼狀況下後者才能到達到優化的目的？有沒有作了改寫以後無效甚至變慢的狀況？

 

 

與此同時，絕大多數查詢都是有篩選條件的，
若是有篩選條件的狀況，
sql語句就變成了select * from t where *** order by id limit m,n
若是如法炮製，改寫成相似
select * from t
inner join (select id from t where *** order by id limit m,n )t1 on t1.id = t.id
在這種狀況下，改寫後的sql語句還能達到優化的目的嗎？

 

 

測試環境搭建

　　測試數據比較簡單，經過存儲過程循環寫入測試數據，測試表的InnoDB引擎表。

　　

　　這裏要注意的是日誌寫入模式必定要修改爲innodb_flush_log_at_trx_commit = 2，不然默認狀況下，500w數據，估計一天都寫不完，這個與日誌寫入模式有關，就很少說了，

 

 

分頁查詢優化的原因

　　首先仍是先看一下這個經典的問題，分頁的時候，越「靠後」查詢相應越慢的狀況

　　測試一：查詢第1-20行的數據，0.01秒

　　

　　一樣是查詢20行數據，查詢相對「靠後」的數據，好比這裏的從4900001-4900020行數據的狀況，用時1.97秒。

　　

　　從中能夠看到，查詢條件不變的狀況下，越日後查詢，查詢效率越低，能夠簡單理解成：一樣搜索20行數據，越是靠後的數據，查詢代價越大。
　　至於爲何後一種效率較低，後面會慢慢分析。

　　測試環境是centos 7 ，mysql 5.7，測試表的數據是500W

　　

 

 

重現經典分頁「優化」，當沒有篩選條件，排序列爲彙集索引的時候，並不會有所改善

這裏來對比如下兩種寫法在彙集索引列做爲排序條件時候的性能
select * from t order by id limit m,n。
select * from t
inner join (select id from t order by id limit m,n)t1 on t1.id = t.id

 

　　第一種寫法：

　　select * from test_table1 order by id asc limit 4900000,20;測試結果見截圖，執行時間爲8.31秒

第二種改寫後的寫法：

select t1.* from test_table1 t1
inner join (select id from test_table1 order by id limit 4900000,20)t2 on t1.id = t2.id;執行時間爲8.43秒

這裏很清楚，經過經典的改寫方法改寫以後，性能能毫無提高,甚至還有一點點變慢了，
實際測試上表現爲二者在性能上並無明顯的線性差別，這二者樓主是作了屢次測試的。

我我的看到相似結論非要測一下不可的，這個東西不能靠蒙，或者靠運氣什麼的，能提升效率是爲何，不能提升又是爲何。

那麼爲何改寫以後的寫法沒有像傳說中的那種提高性能？
是什麼致使當前這個改寫沒有到達提高性能的目的？
後者可以提高性能的原理是什麼？

　　首先看一下測試表的表結構，排序列上是有索引，這一點是沒有問題的，關鍵是這個排序列上的索引是主鍵（彙集索引）。

　　

　　爲何排序列上是彙集索引的時候，相對「優化」改寫以後的sql並不能達到「優化」的目的?

在排序列爲彙集索引列的狀況下，二者都是順序掃描表來實現查詢符合條件的數據的
後者雖然是先驅動一個子查詢，而後再用子查詢的結果驅動主表，
可是子查詢並無改變「順序掃描表來實現查詢符合條件的數據的」作法，當前狀況下，甚至改寫後的作法顯得多此一舉

參考以下二者執行計劃，第一個截圖的執行計劃的一行，與改寫後的sql的執行計劃的第三行（id =2 的那一行），基本上同樣。

　　

　　

 

當沒有篩選條件，排序列爲彙集索引時候的分頁查詢，所謂的分頁查詢優化只不過是多此一舉

　　目前來看，查詢上述數據，兩種方式都很是慢，那若是要查詢上述的數據，該如何作？
　　仍是要看爲何慢，首先要理解B數的平衡性結構，在我本身粗略的理解來看，以下圖，
　　當查詢的數據「靠後」的時候，其實是偏離在B樹索引的一個方向，以下兩個截圖所示的目標數據
　　其實平衡樹上的數據，沒有所謂的「靠前」與「靠後」，「靠前」與「靠後」都是相對於對方來講的，或者說是從掃描的方向上來看的
　　從一個方向上看「靠後的」數據，從一個方向看就是「靠前的」，先後不是絕對的。

 

　　以下兩個截圖是B樹索引結構的粗略表現形式，假如目標數據的位置固定的狀況下，所謂的「靠後」是相對與從左向右來講的；

若是從右向左看，以前所謂靠後的數據其實是「靠前」的。

　　只要數據是靠前的，要高效低找到這部分數據，仍是能夠的。mysql中應該也有相似於sqlserver中的正向（forwarded）和反向掃描（backward）的作法。

　　若是對於靠後的數據，採用反向掃描，應該就能夠很快找到這個部分數據，而後對找到的數據在再次排序（asc），結果應該是同樣的，
　　首先來看效果：結果跟上面的查詢如出一轍，這裏僅耗時0.07秒，以前的兩種寫法均超過了8秒，效率有上百倍的差距。

　　

　　至於這個是爲何，我想根據上面的闡述，本身應該可以體會的到，這裏附上這個sql。
　　若是常常查詢所謂的靠後的數據，好比說Id較大的數據，或者說是時間維度上較新的數據，能夠採用倒敘掃描索引的方式來實現高效分頁查詢

　　（這裏請計算好數據所在的分頁，一樣的數據，正序和倒序其起始「頁碼」是不一樣的）

select* from
(
    select * from test_table1 order by id desc limit 99980,20
    
) t order by id;

 

 

 當沒有篩選條件，排序列爲非彙集索引的時候，會有所改善

　　這裏對測試表test_table1作出以下改變
　　1，增長一個id_2列，
　　2，該字段上建立一個惟一索引，
　　3，該字段用對應的主鍵Id填充

　　

　　上面的測試是按照主鍵索引（彙集索引）來排序的，如今來按照非彙集索引排序，也即新增的這個列id_2來排序，測試一開始提到的兩種分頁方法。

　　首先來看第一種寫法

　　select * from test_table1 order by id_2 asc limit 4900000,20;執行時間爲1分鐘多一點，暫且認其爲60秒

　　

　　第二種寫法

select t1.* from test_table1 t1
inner join (select id from test_table1 order by id_2 limit 4900000,20)t2 on t1.id = t2.id;執行時間1.67秒

　　

　　從這種狀況來看，也就是說排序列爲非彙集索引列的時候，後一種寫法確實能大幅度地提高效率。差很少有40倍的提高。
　　那麼緣由在何呢？
　　首先來看第一種寫法的執行計劃，能夠簡單理解爲這個sql的執行時作全表掃描以後，而後從新按照id_2排序，最後取最前20條數據。
　　首先全表掃描就是一個很是耗時的過程，排序也是一個很是大的代價，所以表現爲性能很是的低下。

 　　

　　再來看後者的執行計劃，他是首先子子查詢中，按照id_2上的索引順序掃描，而後用符合條件的主鍵Id去表中查詢數據
　　這樣的話，避免了查詢出來大量的數據而後從新排序（Using filesort）
　　若是瞭解sqlserver執行計劃的狀況下，後者與前者相比，應該還有避免了頻繁的回表（sqlserver中叫作key lookup或者書籤查找的過程
　　能夠認爲是子查詢驅動外層表查詢符合條件的20條的數據的過程是一個批量的，一次性的。

　　

　　其實，只有在當前狀況下，也就是說排序列爲非彙集索引列的時候，改寫後的sql才能提高分頁查詢的效率。
　　即使如此，此方式「優化」過的分頁語句，仍是與以下寫法的分頁效率有比較大的差異的
　　上面也看到了，返回一樣的數據，以下的查詢是0.07秒，比這裏的1.67秒仍是高2個數量級的

select* from
(
    select * from test_table1 order by id desc limit 99980,20
    
) t order by id;

　　另一個，想提到的問題就是，若是常常性分頁查詢，還要按照某種順序，那麼爲何不在這個列上創建一個彙集索引。
　　好比語句自增Id的，或者時間+其餘字段確保惟一性的，mysql會在主鍵上自動建立彙集索引。
　　而後有了彙集索引，「靠前」與「靠後」僅僅是一個相對的邏輯上的概念了,若是多數時候是想獲得「靠後」或者較新的數據，就能夠採用上述寫法，

 

當存在篩選條件的狀況下，分頁查詢的優化

　　這一部分想了想，狀況太複雜了，很難歸納出來一種很是具備表明性的案例，所以就不過多地作測試了。
　　select * from t where *** order by id limit m,n
　　1，好比刷選條件自己就很高效，一過濾出來僅剩下不多一部分數據，那麼改不改寫sql意義也不大，由於篩選條件自己就能夠作到很高效的篩選
　　2，好比刷選條件自己做用不大（過濾後數據量依然巨大），這種狀況其實又回到了不存在篩選條件的狀況，還有取決於如何排序，正序仍是倒序等等
　　3，好比篩選條件自己做用不大（過濾後數據量依然巨大），要考慮的一個很實際的問題是數據分佈，
　　　　數據的分佈也會影響的sql的執行效率（sqlserver中的經歷，mysql應該差異不大）
　　4，自己查詢比較複雜的狀況下，很難說用某種方式就能夠達到高效的目的

　　狀況越複雜，越是難以總結出來一種通用性的規律或者說是方法，一切都要以具體狀況來看待，很難下一個定論。
　　這裏對於查詢加上篩選條件的狀況，就不作一一分析了，不過能夠確定的是，脫離了實際場景，確定沒有一個固化的方案。

 

　　另外，對於查詢當前頁數據時候，利用上一頁查詢的最大值作篩選條件，也能夠很快滴找到當前頁的數據，這樣固然沒有問題，但這屬於另一個作法，不在本文討論之列。

 

 

　　補充一個在SQL Server下的測試結果，若是是非彙集索引，若是查詢排序的列是一個單列索引，分頁方式並不能提高效率。

create table TestPaging
(
    id int identity(1,1),
    name varchar(50),
    other varchar(100)
)
declare @i int = 0
while @i<100000
begin
    insert into TestPaging values (NEWID(),NEWID())
    set @i = @i + 1
end

create index idx on TestPaging(name)

從執行計劃能夠看出，查詢Id的子查詢是一個全表掃描

 　　除非是一個符合索引，在表中數據比較大的狀況下，才能提升效率（子查詢進行索引掃描的代價要小於全表掃描的代價），不過話說回來，若是常常按照某個列排序分頁，爲何該列上不創建成彙集索引呢？

　　

 

總結

分頁查詢，越靠後越慢的狀況，實則對於B樹索引來講，靠前與靠後是一個邏輯上相對的概念，性能上的差別，是基於B樹索引結構以及掃描方式有關的.若是加上篩選條件，狀況將變得更加複雜，這個問題在SQL Server中的原理也是同樣的，原本也在SQL Server中作了測試的，這裏就不重複了。當前這種狀況，排序列不必定，查詢條件不必定，數據分佈不必定，就很難用一種特定的方法來實現「優化」，弄很差還起到多此一舉的反作用。所以在作分頁優化的時候，必定要根據具體的場景來作分析，方法也不必定只有一種，脫離實際場景的結論，都是扯犢子。惟有弄清楚這個問題的前因後果，才能遊刃有餘。所以我的對於數據「優化」的結論，必定是具體問題具體分析，是很忌諱總結出來一套規則（規則1,2,3,4,5）給人「套用」，鑑於本人也很菜，就更不敢總結出來一些教條了。