隨著用戶對數(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 100GBSSD規(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)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。