分頁場景(limit,offset)爲什麼會慢?

從一個問題說起

五年前在tx的時候,發現分頁場景下,mysql請求速度非常慢。數據量只有10w的情況下,select xx from 單機大概2,3秒。我就問我導師爲什麼,他反問“索引場景,mysql中獲得第n大的數,時間複雜度是多少?”

答案的追尋

確認場景
假設status上面有索引。select * from table where status = xx limit 10 offset 10000。會非常慢。數據量不大的情況就有幾秒延遲。

小白作答
瞎猜了個log(N),心想找一個節點不就是log(N)。自然而然,導師讓我自己去研究。

這一階段,用了10分鐘。

繼續解答
仔細分析一下,會發現通過索引去找很彆扭。因爲你不知道前100個數在左子樹和右子數的分佈情況,所以其是無法利用二叉樹的查找特性。通過學習,瞭解到mysql的索引是b+樹。


看了這個圖,就豁然開朗了。可以直接通過葉子節點組成的鏈表,以o(n)的複雜度找到第100大的樹。但是即使是o(n),也不至於慢得令人髮指,是否還有原因。

這一階段,主要是通過網上查資料,斷斷續續用了10天。

系統學習
這裏推薦兩本書,一本《MySQL技術內幕 InnoDB存儲引擎》,通過他可以對InnoDB的實現機制,如mvcc,索引實現,文件存儲會有更深理解。

第二本是《高性能MySQL》,這本書從着手使用層面,但講得比較深入,而且提到了很多設計的思路。

兩本書相結合,反覆領會,mysql就勉強能登堂入室了。

這裏有兩個關鍵概念:

  • 聚簇索引:包含主鍵索引和對應的實際數據,索引的葉子節點就是數據節點
  • 輔助索引:可以理解爲二級節點,其葉子節點還是索引節點,包含了主鍵id。



    即使前10000個會扔掉,mysql也會通過二級索引上的主鍵id,去聚簇索引上查一遍數據,這可是10000次隨機io,自然慢成哈士奇。這裏可能會提出疑問,爲什麼會有這種行爲,這是和mysql的分層有關係,limit offset 只能作用於引擎層返回的結果集。換句話說,引擎層也很無辜,他並不知道這10000個是要扔掉的。以下是mysql分層示意圖,可以看到,引擎層和server層,實際是分開的。



    直到此時,大概明白了慢的原因。這一階段,用了一年。

觸類旁通
此時工作已經3年了,也開始看一些源碼。在看完etcd之後,看了些tidb的源碼。無論哪種數據庫,其實一條語句的查詢,是由邏輯算子組成。

邏輯算子介紹 在寫具體的優化規則之前,先簡單介紹查詢計劃裏面的一些邏輯算子。

  • DataSource 這個就是數據源,也就是表,select * from t 裏面的 t。
  • Selection 選擇,例如 select xxx from t where xx = 5 裏面的 where 過濾條件。
  • Projection 投影, select c from t 裏面的取 c 列是投影操作。
  • Join 連接, select xx from t1, t2 where t1.c = t2.c 就是把 t1 t2 兩個表做 Join。

選擇,投影,連接(簡稱 SPJ) 是最基本的算子。其中 Join 有內連接,左外右外連接等多種連接方式。

select b from t1, t2 where t1.c = t2.c and t1.a > 5 變成邏輯查詢計劃之後,t1 t2 對應的 DataSource,負責將數據撈上來。上面接個 Join 算子,將兩個表的結果按 t1.c = t2.c連接,再按 t1.a > 5 做一個 Selection 過濾,最後將 b 列投影。下圖是未經優化的表示:



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

怎麼解決

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

方案一
根據業務實際需求,看能否替換爲下一頁,上一頁的功能,特別在ios, android端,以前那種完全的分頁是不常見的。這裏是說,把limit, offset,替換爲>輔助索引(即搜索條件)id的方式。該id再調用時,需要返回給前端。

方案二
正面剛。這裏介紹一個概念:索引覆蓋:當輔助索引查詢的數據,只有id和輔助索引本身,那麼就不必再去查聚簇索引。

思路如下:`select xxx,xxx from in (select id from table where second_index = xxx limit 10 offset 10000)`` 這句話是說,先從條件查詢中,查找數據對應的數據庫唯一id值,因爲主鍵在輔助索引上就有,所以不用迴歸到聚簇索引的磁盤去拉取。再通過這些已經被limit出來的10個主鍵id,去查詢聚簇索引。這樣只會十次隨機io。在業務確實需要用分頁的情況下,使用該方案可以大幅度提高性能。通常能滿足性能要求。

來源 | https://juejin.cn/post/6844903939247177741

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章