使用limit,offset分頁(yè)場(chǎng)景時(shí)會(huì )慢的原因是什么

這篇文章主要介紹使用limit,offset分頁(yè)場(chǎng)景時(shí)會(huì )慢的原因是什么，文中介紹的非常詳細，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

從一個(gè)問(wèn)題說(shuō)起

五年前在騰訊的時(shí)候，發(fā)現分頁(yè)場(chǎng)景下，請求速度非常慢。數據量只有10w的情況下，select xx from 單機大概2，3秒。

我就問(wèn)我師父為什么，他反問(wèn)“索引場(chǎng)景，mysql中獲得第n大的數，時(shí)間復雜度是多少？”

答案的追尋

確認場(chǎng)景

假設status上面有索引。select * from table where status = xx limit 10 offset 10000。

會(huì )非常慢。數據量不大的情況就有幾秒延遲。

小白作答

那時(shí)候非常有安全感，有啥事都有師父兜著(zhù)，反正技術(shù)都是組里最差的，就瞎猜了個(gè)log(N)，心想找一個(gè)節點(diǎn)不就是log(N)。自然而然，師父讓我自己去研究。

這一階段，用了10分鐘。

繼續解答

仔細分析一下，會(huì )發(fā)現通過(guò)索引去找很別扭。因為你不知道前100個(gè)數在左子樹(shù)和右子數的分布情況，所以其是無(wú)法利用二叉樹(shù)的查找特性。

通過(guò)學(xué)習，了解到mysql的索引是b+樹(shù)。

看了這個(gè)圖，就豁然開(kāi)朗了?？梢灾苯油ㄟ^(guò)葉子節點(diǎn)組成的鏈表，以o(n)的復雜度找到第100大的樹(shù)。但是即使是o(n)，也不至于慢得令人發(fā)指，是否還有原因。

這一階段，主要是通過(guò)網(wǎng)上查資料，斷斷續續用了10天。

系統學(xué)習

這里推薦兩本書(shū)，一本《MySQL技術(shù)內幕 InnoDB存儲引擎》，通過(guò)他可以對InnoDB的實(shí)現機制，如mvcc，索引實(shí)現，文件存儲會(huì )有更深理解。

第二本是《高性能MySQL》，這本書(shū)從著(zhù)手使用層面，但講得比較深入，而且提到了很多設計的思路。

兩本書(shū)相結合，反復領(lǐng)會(huì )，mysql就勉強能登堂入室了。

這里有兩個(gè)關(guān)鍵概念：

• 聚簇索引：包含主鍵索引和對應的實(shí)際數據，索引的葉子節點(diǎn)就是數據節點(diǎn)

• 輔助索引：可以理解為二級節點(diǎn)，其葉子節點(diǎn)還是索引節點(diǎn)，包含了主鍵id。

即使前10000個(gè)會(huì )扔掉，mysql也會(huì )通過(guò)二級索引上的主鍵id,去聚簇索引上查一遍數據，這可是10000次隨機io，自然慢成哈士奇。

這里可能會(huì )提出疑問(wèn)，為什么會(huì )有這種行為，這是和mysql的分層有關(guān)系，limit offset 只能作用于引擎層返回的結果集。換句話(huà)說(shuō)，引擎層也很無(wú)辜，他并不知道這10000個(gè)是要扔掉的。

以下是mysql分層示意圖，可以看到，引擎層和server層，實(shí)際是分開(kāi)的。

直到此時(shí)，大概明白了慢的原因。這一階段，用了一年。

觸類(lèi)旁通

此時(shí)工作已經(jīng)3年了，也開(kāi)始看一些源碼。在看完etcd之后，看了些tidb的源碼。無(wú)論哪種數據庫，其實(shí)一條語(yǔ)句的查詢(xún)，是由邏輯算子組成。

邏輯算子介紹

在寫(xiě)具體的優(yōu)化規則之前，先簡(jiǎn)單介紹查詢(xún)計劃里面的一些邏輯算子。

• DataSource 這個(gè)就是數據源，也就是表，select * from t 里面的 t。

• Selection 選擇，例如 select xxx from t where xx = 5 里面的 where 過(guò)濾條件。

• Projection 投影， select c from t 里面的取 c 列是投影操作。

• Join 連接， select xx from t1, t2 where t1.c = t2.c 就是把 t1 t2 兩個(gè)表做 Join。

選擇，投影，連接（簡(jiǎn)稱(chēng) SPJ） 是最基本的算子。其中 Join 有內連接，左外右外連接等多種連接方式。

select b from t1, t2 where t1.c = t2.c and t1.a > 5變成邏輯查詢(xún)計劃之后，t1 t2 對應的 DataSource，負責將數據撈上來(lái)。

上面接個(gè) Join 算子，將兩個(gè)表的結果按 t1.c = t2.c連接，再按 t1.a > 5 做一個(gè) Selection 過(guò)濾，最后將 b 列投影。

下圖是未經(jīng)優(yōu)化的表示：

所以說(shuō)不是mysql不想把limit, offset傳遞給引擎層，而是因為劃分了邏輯算子，所以導致無(wú)法直到具體算子包含了多少符合條件的數據。

怎么解決

《高性能MySQL》提到了兩種方案

方案一

根據業(yè)務(wù)實(shí)際需求，看能否替換為下一頁(yè)，上一頁(yè)的功能，特別在ios, android端，以前那種完全的分頁(yè)是不常見(jiàn)的。

這里是說(shuō)，把limit, offset，替換為>輔助索引（即搜索條件）id的方式。該id再調用時(shí)，需要返回給前端。

方案二

正面剛。這里介紹一個(gè)概念：索引覆蓋：當輔助索引查詢(xún)的數據，只有id和輔助索引本身，那么就不必再去查聚簇索引。

思路如下：select xxx,xxx from in (select id from table where second_index = xxx limit 10 offset 10000)這句話(huà)是說(shuō)，先從條件查詢(xún)中，查找數據對應的數據庫唯一id值，因為主鍵在輔助索引上就有，所以不用回歸到聚簇索引的磁盤(pán)去拉取。再通過(guò)這些已經(jīng)被limit出來(lái)的10個(gè)主鍵id，去查詢(xún)聚簇索引。這樣只會(huì )十次隨機io。

在業(yè)務(wù)確實(shí)需要用分頁(yè)的情況下，使用該方案可以大幅度提高性能。通常能滿(mǎn)足性能要求。