分頁(yè)場(chǎng)景慢的原因有哪些

本篇內(nèi)容主要講解“分頁(yè)場(chǎng)景慢的原因有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“分頁(yè)場(chǎng)景慢的原因有哪些”吧!

目前創(chuàng)新互聯(lián)公司已為近1000家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)頁(yè)空間、網(wǎng)站托管維護(hù)、企業(yè)網(wǎng)站設(shè)計(jì)、博州網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

從一個(gè)問題說起

五年前在tx的時(shí)候，發(fā)現(xiàn)分頁(yè)場(chǎng)景下，MySQL請(qǐng)求速度非常慢。數(shù)據(jù)量只有10w的情況下，select xx from 單機(jī)大概2，3秒。我就問我導(dǎo)師為什么，他反問“索引場(chǎng)景，mysql中獲得第n大的數(shù)，時(shí)間復(fù)雜度是多少？”

答案的追尋

確認(rèn)場(chǎng)景假設(shè)status上面有索引。select * from table where status = xx limit 10 offset 10000。會(huì)非常慢。數(shù)據(jù)量不大的情況就有幾秒延遲。

小白作答瞎猜了個(gè)log(N)，心想找一個(gè)節(jié)點(diǎn)不就是log(N)。自然而然，導(dǎo)師讓我自己去研究。

這一階段，用了10分鐘。

繼續(xù)解答仔細(xì)分析一下，會(huì)發(fā)現(xiàn)通過索引去找很別扭。因?yàn)槟悴恢狼?00個(gè)數(shù)在左子樹和右子數(shù)的分布情況，所以其是無法利用二叉樹的查找特性。通過學(xué)習(xí)，了解到mysql的索引是b+樹。 看了這個(gè)圖，就豁然開朗了?？梢灾苯油ㄟ^葉子節(jié)點(diǎn)組成的鏈表，以o(n)的復(fù)雜度找到第100大的樹。但是即使是o(n)，也不至于慢得令人發(fā)指，是否還有原因。

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

系統(tǒng)學(xué)習(xí)這里推薦兩本書，一本《MySQL技術(shù)內(nèi)幕 InnoDB存儲(chǔ)引擎》，通過他可以對(duì)InnoDB的實(shí)現(xiàn)機(jī)制，如mvcc，索引實(shí)現(xiàn)，文件存儲(chǔ)會(huì)有更深理解。

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

兩本書相結(jié)合，反復(fù)領(lǐng)會(huì)，mysql就勉強(qiáng)能登堂入室了。

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

• 聚簇索引：包含主鍵索引和對(duì)應(yīng)的實(shí)際數(shù)據(jù)，索引的葉子節(jié)點(diǎn)就是數(shù)據(jù)節(jié)點(diǎn)

• 輔助索引：可以理解為二級(jí)節(jié)點(diǎn)，其葉子節(jié)點(diǎn)還是索引節(jié)點(diǎn)，包含了主鍵id。 即使前10000個(gè)會(huì)扔掉，mysql也會(huì)通過二級(jí)索引上的主鍵id,去聚簇索引上查一遍數(shù)據(jù)，這可是10000次隨機(jī)io，自然慢成哈士奇。這里可能會(huì)提出疑問，為什么會(huì)有這種行為，這是和mysql的分層有關(guān)系，limit offset 只能作用于引擎層返回的結(jié)果集。換句話說，引擎層也很無辜，他并不知道這10000個(gè)是要扔掉的。以下是mysql分層示意圖，可以看到，引擎層和server層，實(shí)際是分開的。 直到此時(shí)，大概明白了慢的原因。這一階段，用了一年。

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

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

• DataSource 這個(gè)就是數(shù)據(jù)源，也就是表，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 兩個(gè)表做 Join。

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

select b from t1, t2 where t1.c = t2.c and t1.a > 5 變成邏輯查詢計(jì)劃之后，t1 t2 對(duì)應(yīng)的 DataSource，負(fù)責(zé)將數(shù)據(jù)撈上來。上面接個(gè) Join 算子，將兩個(gè)表的結(jié)果按 t1.c = t2.c連接，再按 t1.a > 5 做一個(gè) Selection 過濾，最后將 b 列投影。下圖是未經(jīng)優(yōu)化的表示： 所以說不是mysql不想把limit, offset傳遞給引擎層，而是因?yàn)閯澐至诉壿嬎阕?，所以?dǎo)致無法直到具體算子包含了多少符合條件的數(shù)據(jù)。

怎么解決

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

方案一根據(jù)業(yè)務(wù)實(shí)際需求，看能否替換為下一頁(yè)，上一頁(yè)的功能，特別在ios, android端，以前那種完全的分頁(yè)是不常見的。這里是說，把limit, offset，替換為>輔助索引（即搜索條件）id的方式。該id再調(diào)用時(shí)，需要返回給前端。

方案二正面剛。這里介紹一個(gè)概念：索引覆蓋：當(dāng)輔助索引查詢的數(shù)據(jù)，只有id和輔助索引本身，那么就不必再去查聚簇索引。

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

到此，相信大家對(duì)“分頁(yè)場(chǎng)景慢的原因有哪些”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

分享文章：分頁(yè)場(chǎng)景慢的原因有哪些
當(dāng)前地址：http://muchs.cn/article2/ghipic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、網(wǎng)站營(yíng)銷、品牌網(wǎng)站設(shè)計(jì)、關(guān)鍵詞優(yōu)化、品牌網(wǎng)站建設(shè)、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)