千萬級數(shù)據(jù)深分頁查詢SQL性能優(yōu)化實踐

2023-08-23 23:18:07 來源：博客園

一、系統(tǒng)介紹和問題描述

如何在Mysql中實現(xiàn)上億數(shù)據(jù)的遍歷查詢？先來介紹一下系統(tǒng)主角：關注系統(tǒng)，主要是維護京東用戶和業(yè)務對象之前的關注關系；并對外提供各種關系查詢，比如查詢用戶的關注商品或店鋪列表，查詢用戶是否關注了某個商品或店鋪等。但是最近接到了一個新需求，要求提供查詢關注對象的粉絲列表接口功能。該功能的難點就是關注對象的粉絲數(shù)量過多，不少店鋪的粉絲數(shù)量都是千萬級別，并且有些大V粉絲數(shù)量能夠達到上億級別。而這些粉絲列表數(shù)據(jù)目前全都存儲在Mysql庫中，然后通過業(yè)務對象ID進行分庫分表，所有的粉絲列表數(shù)據(jù)分布在16個分片的256張表中。同時為了方便查詢粉絲列表，同一個業(yè)務對象的所有粉絲都會路由到同一張表中，每個表的數(shù)據(jù)量都能夠達到 2 億+。

二、解決問題的思路和方法

數(shù)據(jù)庫表結構示例如下：

(資料圖)

CREATE TABLE follow_fans_[0-255]  (    id bigint(11) NOT NULL AUTO_INCREMENT COMMENT "自增id",    biz_content   VARCHAR(50) DEFAULT NULL COMMENT "業(yè)務對象ID",    source        VARCHAR(50) DEFAULT NULL COMMENT "來源",    pin           VARCHAR(50) DEFAULT NULL COMMENT "用戶pin",    ext           VARCHAR(5000) DEFAULT NULL COMMENT "擴展信息",    status        TINYINT(2) DEFAULT 1 COMMENT "狀態(tài)，0是失效，1是正常",    created_time  DATETIME DEFAULT NULL COMMENT "創(chuàng)建時間",    modified_time DATETIME DEFAULT NULL COMMENT "修改時間",    PRIMARY KEY(id),    UNIQUE INDEX uniq_biz_content_pin (biz_content, pin)  )  ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT = "關注粉絲表";

Limit實現(xiàn)

由于同一個業(yè)務對象的所有粉絲都保存到一張數(shù)據(jù)庫表中，對于分頁查詢列表接口，首先想到的就是用limit實現(xiàn)，對于粉絲數(shù)量很少的關注對象，查詢接口性能還不錯。但是隨著關注對象的粉絲數(shù)量越來越多，接口查詢性能就會越來越慢。后來經(jīng)過接口壓測，當業(yè)務對象粉絲列表數(shù)量達到幾十萬級別的時候，查詢頁碼數(shù)量越大，查詢耗時越多。limit深分頁為什么會變慢？這就和sql的執(zhí)行計劃有關了，limit語句會先掃描offset+n行，然后再丟棄掉前offset行，返回后n行數(shù)據(jù)。也就是說limit 100000,10，就會掃描100010行，而limit 0,10，只掃描10行。查詢 sql 示例如下：

select  id,biz_content,pin FROM follow_fans_1 where biz_content = #{bizContent} order by id desc limit 10, 10;

方案優(yōu)點：實現(xiàn)簡單，支持跳頁查詢。方案缺點：數(shù)據(jù)量變大時，隨著查詢頁碼的深入，查詢性能越來越差。標簽記錄法

Limit深分頁問題的本質(zhì)原因就是：偏移量（offset）越大，mysql就會掃描越多的行，然后再拋棄掉，這樣就導致查詢性能的下降。所以我們可以采用標簽記錄法，就是標記一下上次查詢到哪一條了，下次再來查的時候，從該條開始往下掃描。具體做法方式是，查詢粉絲列表中按照自增主鍵ID倒序查詢，查詢結果中返回主鍵ID，然后查詢?nèi)雲(yún)⒅性黾觤axId參數(shù)，該參數(shù)需要透傳上一次請求粉絲列表中最后一條記錄主鍵ID，第一次查詢時可以為空，但是需要查詢下一頁時就必傳。最后根據(jù)查詢時返回的行數(shù)是否等于 10 來判斷整個查詢是否可以結束。優(yōu)化后的查詢sql參考如下：

select id,biz_content,pin FROM follow_fans_1 where biz_content = #{bizContent} and id < #{lastId} order by id desc limit 10;

方案優(yōu)點：避免了數(shù)據(jù)量變大時，頁碼查詢深入的性能下降問題；經(jīng)過接口壓測，千萬級數(shù)據(jù)量時，前 N-1頁查詢耗時可以控制在幾十毫秒內(nèi)。方案缺點：只能支持按照頁碼順序查詢，不支持跳頁，而且僅能保證前 N-1 頁的查詢性能；如果最后一頁的表中行數(shù)量不滿 10 條時，引擎不知道何時終止查詢，只能遍歷全表，所以當表中數(shù)據(jù)量很大時，還是會出現(xiàn)超時情況。區(qū)間限制法

標簽記錄法最后一頁查詢超時就是因為不知道何時終止查詢，所以我們可以提供一個區(qū)間限制范圍來告訴引擎查詢到此結束。

查詢sql再次優(yōu)化后參考如下：

select id,biz_content,pin FROM follow_fans_1 where biz_content = #{bizContent} and id < #{lastId} and id >={minId} order by id desc limit 10;

由于查詢時需要帶上 minId 參數(shù)，所以在執(zhí)行查詢粉絲列表之前，我們就需要先把 minId 查詢出來，查詢 sql 參考如下：

select min(id) from follow_fans_1 where biz_content = #{bizContent}

由于表中數(shù)據(jù)量太大，每個表中總數(shù)據(jù)量都是上億級別，導致第一步查詢 minId就直接超時了，根本沒有機會去執(zhí)行第二步。但是考慮到上一個查詢方案只有最后一頁才會查詢超時，前N-1頁查詢根本用不到 minId 作為區(qū)間限制。所以當表中數(shù)據(jù)量很大時，通常從第一頁到最后一頁查詢之間會存在一定的時間差。我們就可以正好去利用這個時間差去異步查詢minId，然后將查詢出來的minId存儲到緩存中，考慮到這個 minId 可能會被刪除，可以設置一定的過期時間。最后優(yōu)化后的查詢流程如下：

調(diào)用查詢粉絲列表方法時首先查詢緩存minId；如果緩存minId 為空，則創(chuàng)建異步任務去執(zhí)行select min(id) 查詢表中的 minId,然后回寫緩存，該異步任務執(zhí)行時間可能會很長，可以單獨設置超時時間。如果緩存minId不為空，則在查詢sql中拼接查詢條件id >={minId}，從而保證查詢最后一頁時不會超時。

但是在上述方案中，如果表中的數(shù)據(jù)量達到上億級別時，第二步的異步獲取minId任務還是會存在超時的風險，從而導致查詢最后一頁粉絲列表出現(xiàn)超時。所以我們又引入了離線數(shù)據(jù)計算任務，通過在大數(shù)據(jù)平臺離線計算獲取每個biz_content下的minId,然后將計算結果minId推送到緩存中。為了保證minId能夠及時更新，我們可以自由設置該離線任務的執(zhí)行周期，比如每周執(zhí)行一次。通過大數(shù)據(jù)平臺的離線計算minId，從而大大減少了在查詢粉絲列表時執(zhí)行 select min(id）的業(yè)務數(shù)據(jù)庫壓力。只有當緩存沒有命中的時候才去執(zhí)行 select min(id)，通常這些緩存沒有命中的 minId 也都是一些被離線任務遺漏的少量數(shù)據(jù)，不會影響接口的整體查詢性能。

方案優(yōu)點：避免了數(shù)據(jù)量變大時，頁碼查詢深入的性能下降問題；經(jīng)過接口壓測，千萬級數(shù)據(jù)量時，從第一頁到最后一頁都控制在幾十毫秒內(nèi)。方案缺點：只能支持按照頁碼順序和主鍵ID倒序查詢，不支持跳頁查詢，并且還需要依賴大數(shù)據(jù)平臺離線計算和額外的緩存來存儲 minId。三、對SQL優(yōu)化治理的思考

通過對以上三種方案的探索實踐，發(fā)現(xiàn)每一種方案都有自己的優(yōu)缺點和它的適用場景，我們不能脫離實際業(yè)務場景去談方案的好壞。所以我們要結合實際的業(yè)務環(huán)境以及表中數(shù)據(jù)量的大小去綜合考慮、權衡利弊，然后找到更適合的技術方案。以下是總結的幾條SQL優(yōu)化建議：

查詢條件一定要有索引

索引主要分為兩大類，聚簇索引和非聚簇索引，可以通過 explain 查看 sql 執(zhí)行計劃判斷查詢是否使用了索引。

聚簇索引 (clustered index)：聚簇索引的葉子節(jié)點存儲行記錄，InnoDB必須要有且只有一個聚簇索引：

如果表定義了主鍵，則主鍵索引就是聚簇索引；如果沒有定義主鍵，則第一個非空的唯一索引列是聚簇索引；如果沒有唯一索引，則創(chuàng)建一個隱藏的row-id列作為聚簇索引。主鍵索引查詢非?？?，可以直接定位行記錄。

非聚簇索引（secondary index)：InnoDB非聚簇索引的葉子節(jié)點存儲的是行記錄的主鍵值，而MyISAM葉子節(jié)點存儲的是行指針。通常情況下，需要先遍歷非聚簇索引獲得聚簇索引的主鍵ID，然后在遍歷聚簇索引獲取對應行記錄。

正確使用索引，防止索引失效

可以參考以下幾點索引原則：

最左前綴匹配原則，mysql會一直向右匹配直到遇到范圍查詢（>、<、between、like）就停止匹配，比如 a=1 and b=2 and c>3 and d=4 ，如果建立了（a,b,c,d)順序的索引，d是用不到索引的，如果建立（a,b,d,c)的索引則都可以用到，a、b、d的順序可以任意調(diào)整。=和in可以亂序，比如 a=1 and b=2 and c=3 建立（a,b,c)索引可以任意順序，mysql的查詢優(yōu)化器會幫助優(yōu)化成索引可以識別的形式。盡量選擇區(qū)分度高德列作為索引，區(qū)分度公式count(distinct col)/count(*)，表示字段不重復的比例。索引列不能使用函數(shù)或參與計算，不能進行類型轉換，否則索引會失效。盡量擴展索引，不要新建索引。減少查詢字段，避免回表查詢

回表查詢就是先定位主鍵值，在根據(jù)主鍵值定位行記錄，需要掃描兩遍索引。解決方案：只需要在一顆索引樹上能夠獲取SQL所需要的所有列數(shù)據(jù)，則無需回表查詢，速度更快。可以將要查詢的字段，建立到聯(lián)合索引里去，這就是索引覆蓋。查詢sql在進行explain解析時，Extra字段為Using Index時，則觸發(fā)索引覆蓋。沒有觸發(fā)索引覆蓋，發(fā)生了回表查詢時，Extra字段為Using Index condition。