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

 

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

 

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

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

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

 

 

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

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服務器

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

 

 

與此同時,絕大多數查詢都是有篩選條件的,
若是有篩選條件的狀況,
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語句還能達到優化的目的嗎?sqlserver

 

 

測試環境搭建性能

  測試數據比較簡單,經過存儲過程循環寫入測試數據,測試表的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)給人「套用」,鑑於本人也很菜,就更不敢總結出來一些教條了。

相關文章
相關標籤/搜索