快捷導(dǎo)航

MySQL緩存優(yōu)化方案總結(jié)

更新時(shí)間：2023年08月23日 09:03:58 作者：在下uptown

最近迭代的產(chǎn)品版本從2.X來(lái)到了3.X,屬于一個(gè)非常大的產(chǎn)品升級(jí),比上個(gè)版本多了很多功能,那么上線之前肯定要在一個(gè)干凈的環(huán)境里進(jìn)行測(cè)試回歸以及性能測(cè)試,本文總結(jié)一下數(shù)據(jù)庫(kù)層面的一些緩存機(jī)制對(duì)查詢(xún)速度整體的優(yōu)化,需要的朋友可以參考下

查詢(xún)緩存

想必大家應(yīng)該都知道這個(gè)相對(duì)比較雞肋的querycahce機(jī)制，從誕生以來(lái)就不怎么受人待見(jiàn)，在mysql5.6將該機(jī)制默認(rèn)關(guān)閉，到了mysql8直接將他取消了。

查詢(xún)緩存顧名思義是將查詢(xún)的結(jié)果集緩存住，可以簡(jiǎn)單理解為整個(gè)sql為key，緩存sql的結(jié)果，每一次select查詢(xún)都會(huì)先檢查querycache是否有緩存，如果存在緩存的數(shù)據(jù)則直接返回，相比于磁盤(pán)讀取性能提升n倍。

聽(tīng)起來(lái)十分合理，但缺點(diǎn)也十分明顯：

基于sql來(lái)緩存嚴(yán)格到字節(jié)級(jí)別，只要sql中多一個(gè)空格就不會(huì)走緩存。對(duì)于線上環(huán)境比較生硬。
只適用于讀多遠(yuǎn)大于寫(xiě)少的場(chǎng)景，一有ddl預(yù)計(jì)緩存就會(huì)失效。
打開(kāi)查詢(xún)緩存后如果一條sql沒(méi)有命中會(huì)消耗額外的資源把結(jié)果集維護(hù)起來(lái)，浪費(fèi)資源

所以一般的線上環(huán)境都不推薦使用這個(gè)機(jī)制。

表緩存

如果大家有背過(guò)mysql的八股文一定對(duì)innodb_buffer_pool_size這個(gè)參數(shù)不陌生，既然叫innodb_buffer說(shuō)明這是innodb引擎特有的參數(shù)，負(fù)責(zé)緩存磁盤(pán)中的數(shù)據(jù)減少磁盤(pán)IO提升讀寫(xiě)速度。

由于innodb讀取數(shù)據(jù)的基本單位是頁(yè)并且使用B+樹(shù)索引結(jié)構(gòu)來(lái)組織數(shù)據(jù)，每個(gè)索引頁(yè)通常包含多個(gè)數(shù)據(jù)行，數(shù)據(jù)行按照主鍵的順序進(jìn)行排序。通過(guò)主鍵索引，可以快速定位到目標(biāo)數(shù)據(jù)行所在的索引頁(yè)，然后讀取對(duì)應(yīng)的磁盤(pán)頁(yè)。

每次讀取數(shù)據(jù)會(huì)連帶著整條數(shù)據(jù)頁(yè)被加載，好不容易消耗了資源讀磁盤(pán)拿出來(lái)的數(shù)據(jù)不能浪費(fèi)，理所當(dāng)然的存在了buffer_pool里，比如第一次查詢(xún)select * from A where id = 1，在1附近的數(shù)據(jù)都被緩存到了buffer_pool中，下一次執(zhí)行select * from A where id = 2時(shí)就會(huì)從緩沖池里拿。

并且buffer_pool通過(guò)change_buffer來(lái)記錄增刪改對(duì)數(shù)據(jù)的變更操作，這樣就會(huì)極大的優(yōu)化查詢(xún)速度并節(jié)省性能，緩存失效也會(huì)根據(jù)LRU的機(jī)制去淘汰舊緩存。

從這次產(chǎn)品迭代升級(jí)的新環(huán)境中發(fā)現(xiàn)，部署一個(gè)新的mysql容器可以注意調(diào)整一下innodb_buffer_pool_size對(duì)應(yīng)的值，默認(rèn)為128M，通過(guò)以下命令查看。

show variables like '%innodb_buffer_pool_size%';

一般我們可以調(diào)整為機(jī)器內(nèi)存的1/4，這個(gè)可以視情況而定，修改完之后會(huì)發(fā)現(xiàn)性能提升一大截。

ReadySet

先放一下官方文檔:

Home – ReadySet

上面的都是MySQL自帶的緩存方案，這個(gè)組件是最近逛github的時(shí)候碰巧看到的中間件，一個(gè)高性能且輕量的mysql&pg數(shù)據(jù)庫(kù)緩存解決方案，無(wú)需額外代碼即可將最復(fù)雜的 SQL 讀取轉(zhuǎn)變?yōu)?strong>閃電般快速的查找。本質(zhì)上基于jdbc實(shí)現(xiàn)了一套服務(wù)，對(duì)上層而言就是一個(gè)數(shù)據(jù)庫(kù)，

由于我也是剛接觸不是特別了解只能簡(jiǎn)單聊一下，它本質(zhì)上是用一個(gè)數(shù)據(jù)流圖的機(jī)制去做的，所謂數(shù)據(jù)流圖按我理解就是一個(gè)快照，基于用戶(hù)的sql構(gòu)建一個(gè)快照，后續(xù)的增刪改語(yǔ)句與buffer pool思路一樣，在內(nèi)存中計(jì)算。

這個(gè)方案思路上有點(diǎn)類(lèi)似mysql中的查詢(xún)緩存和buffer_pool的整合版本，也是通過(guò)sql去緩存數(shù)據(jù)，需要主動(dòng)通過(guò)使用CREATE CACHE FROMSQL擴(kuò)展，將查詢(xún)緩存在ReadySet中，通過(guò)SHOW CACHES查看所有緩存SQL，然后緩存的數(shù)據(jù)本質(zhì)上是構(gòu)造了快照，有數(shù)據(jù)更新會(huì)監(jiān)聽(tīng)binlog同步到快中中并支持最終一致性保持緩存一致，當(dāng)然會(huì)有一點(diǎn)點(diǎn)的數(shù)據(jù)延遲。

所以這類(lèi)中間件用著用著就會(huì)帶來(lái)巨大的內(nèi)存開(kāi)銷(xiāo)，不過(guò)在BI類(lèi)似的平臺(tái)中可以試一試。

到此這篇關(guān)于MySQL緩存優(yōu)化方案總結(jié)的文章就介紹到這了,更多相關(guān)MySQL緩存優(yōu)化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: