隨著用戶對數(shù)據(jù)訪問速度的日益重視,MySQL數(shù)據(jù)庫在最初的設計中,采用了線性預讀的方式,提前將即將使用的數(shù)據(jù)預讀到Buffer pool中,來提升數(shù)據(jù)的訪問速度,但在實際使用過程中,線性預讀失效的問題愈來愈突出。

對于存在時間比較長,變更又比較頻繁,除非我們對于這張表進行重建,否則該表會存在大量的數(shù)據(jù)碎片,導致數(shù)據(jù)存放不連續(xù),這樣會使MySQL原有的線性預讀功能失效,導致某些查詢語句變很慢,如:全表掃描,范圍掃描等。

頻繁變更操作會破壞數(shù)據(jù)的連續(xù)性

一般情況下,當我們在數(shù)據(jù)存放連續(xù)時執(zhí)行全表掃描,數(shù)據(jù)庫就會異步地把這些數(shù)據(jù)從磁盤加載到Buffer pool,從而提高數(shù)據(jù)庫的處理速度。比如當我們訪問了Row A1,Row A2,Row A3時,數(shù)據(jù)庫會認為你下次有極大的概率去訪問Row A4,Row A5,Row A6,從而自動異步地把這些數(shù)據(jù)加載到Buffer pool中。

但如果在這張表上頻繁地執(zhí)行變更操作,則會破壞數(shù)據(jù)的連續(xù)性。在我們訪問Row A1,Row A2,Row A3時,數(shù)據(jù)庫發(fā)現(xiàn)這三行數(shù)據(jù)并不連續(xù),所以數(shù)據(jù)庫不會提前將Row A5,Row A6從磁盤異步地加載到Buffer pool,只能一個一個的去請求、加載,從而影響訪問效率。數(shù)據(jù)連續(xù)時,訪問500w Row數(shù)據(jù)需要12s,但是數(shù)據(jù)不連續(xù)時,訪問500w Row數(shù)據(jù)需要34s。

對于在線應用來說,重建表會產(chǎn)生較大的運維風險,數(shù)據(jù)面臨丟失的可能。那到底有沒有什么特性可以在不重建表的情況下,彌補線性預讀失效的問題呢?

線性預讀的失效催生出“邏輯預讀”特性

華為云RDS數(shù)據(jù)庫服務,新開發(fā)了“邏輯預讀”特性,在不重建表的情況下,彌補線性預讀失效的問題,從而提高分析型業(yè)務的執(zhí)行效率。

“邏輯預讀”特性,在預讀數(shù)據(jù)的時候,首先通過對要預讀的數(shù)據(jù)的頁號進行排序,去除數(shù)據(jù)不連續(xù)的影響,然后合并相鄰數(shù)據(jù)頁的IO請求,減少磁盤IO的總請求次數(shù),從而提高數(shù)據(jù)預讀的命中率和效率。

華為云數(shù)據(jù)庫團隊做了一個測試:采用8核16GB 100GB?SSD規(guī)格的Linux機器,測試2.4GB大小500w Rows存在碎片的數(shù)據(jù),執(zhí)行select *from tablename(全表掃描查詢),結果如下:

由此可見,相比開源版本,華為云MySQL邏輯預讀特性大大縮短了訪問時長,極大提升了執(zhí)行效率,為分析型業(yè)務的進一步發(fā)展注入了新動力。

每一個改變都是為了更好的服務客戶,華為云MySQL邏輯預讀特性的推出,不僅很好地彌補了線性預讀的失效問題,提升了分析型業(yè)務的執(zhí)行效率,更是為客戶的業(yè)務場景保駕護航,助力其創(chuàng)新發(fā)展,實現(xiàn)更多價值。

更多詳情了解,敬請前往華為云官網(wǎng):產(chǎn)品——基礎服務——數(shù)據(jù)庫。

(本內容屬于網(wǎng)絡轉載，文中涉及圖片等內容如有侵權，請聯(lián)系編輯刪除)

總結

以上是生活随笔為你收集整理的MySQL预读失效_华为云MySQL新增“逻辑预读”特性，轻松解决线性预读失效问题...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。