從一個問題說起

五年前在騰訊的時候，發現分頁場景下，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。

在業務確實需要用分頁的情況下，使用該方案可以大幅度提高效能。通常能滿足效能要求。

寫在最後

非常感謝我師父在我畢業前三年的指導，給了我很多耐心。在節假日給我佈置看書任務，在午休時候考察我學習的進展，通過提問的方式引導我去探索問題，在我從騰訊畢業後，每次見面也給我出了很多主意，傳授授業解惑，無一沒有做到極致。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。