深入理解MySQL中MVCC與BufferPool緩存機制
一、MVCC機制
- MVCC(Multi Version Concurrency Control),MySQL(默認)RR隔離級別就是通過該機制來保證的,對一行數(shù)據(jù)的讀與寫兩個操作默認是不會通過加鎖互斥來保證隔離性的
- 串行化隔離級別是為了保證較高的隔離性,是通過將所有操作加鎖互斥來實現(xiàn)的
- MySQL在RC隔離級別和RR隔離級別下都實現(xiàn)了MVCC機制
- RC每次查詢都會創(chuàng)建一個reade-view,而RR在創(chuàng)建完read-view之后,在不提交事務(wù)之前,每次查詢還是第一次創(chuàng)建的read-view
undo日志版本鏈與read-view機制
- undo日志版本鏈?zhǔn)侵敢恍袛?shù)據(jù)被多個事務(wù)一次修改后,當(dāng)每個事務(wù)修改完之后,MySQL會保留修改前的數(shù)據(jù)undo回滾日志,并且用兩個隱藏字段trx_id和roll_pointer把只寫undo日志串聯(lián)起來形成一個歷史記錄版本鏈.
- RR隔離級別,當(dāng)事務(wù)開啟,執(zhí)行任何SQL時會生成當(dāng)前事務(wù)的read-view一致性視圖,該視圖在事務(wù)結(jié)束之前都不會變化(如果是RC隔離界別在每次執(zhí)行查詢SQL時都會重新生成最新的read-view),這個視圖由執(zhí)行查詢時所有未提交的事務(wù)id數(shù)組(數(shù)組里最小的id為min_id)和已創(chuàng)建的最大事務(wù)id(max_id)組成,事務(wù)里任何SQL查詢結(jié)果需要從對應(yīng)版本鏈里的最新數(shù)據(jù)開始逐條跟read-view作比對,從而得到最終的結(jié)果
版本鏈比對規(guī)則
- 如果row的trx_id落在綠色部分(trx < min_id),表示這個版本是已提交的事務(wù)生成的,這個數(shù)據(jù)是可見的
- 如果row的trx_id落在紅色部分(trx > max_id),表示這個版本是由將來啟動的(未開始)事務(wù)生成的,是不可見的(若row的trx_id就是當(dāng)前自己的事務(wù)是可見的)
- 如果 row 的 trx_id 落在黃色部分(min_id <= trx_id <= max_id),那就包括兩種情況
- 若 row 的 trx_id 在視圖數(shù)組中,表示這個版本是由還沒提交的事務(wù)生成的不可見(若 row 的 trx_id 就是當(dāng)前自己的事務(wù)是可見的)
- 若 row 的 trx_id 不在視圖數(shù)組中,表示這個版本是已經(jīng)提交了的事務(wù)生成的可見
二、BufferPool機制
InnoDB執(zhí)行的BufferPool緩存機制:
InnoDB的SQL執(zhí)行流程:
- 當(dāng)客戶端執(zhí)行一條修改的SQL,需要經(jīng)過Server層,再調(diào)用具體的執(zhí)行引擎
- 加載數(shù)據(jù)頁,把需要修改數(shù)據(jù)所在的數(shù)據(jù)頁,緩存到BufferPool
- 修改前寫undo日志,記錄更改前數(shù)據(jù),如果事務(wù)執(zhí)行失敗,使用undo日志進行數(shù)據(jù)回滾
- 更新BufferPool中的數(shù)據(jù)
- 準(zhǔn)備提交事務(wù)寫redo日志,保存操作記錄。redo日志用來恢復(fù)已提交事務(wù)的BufferPool
- 準(zhǔn)備提交事務(wù)寫binlog日志,保存操作記錄。binlog日志用來恢復(fù)磁盤數(shù)據(jù)
- 事務(wù)提交完成,此時binlog日志寫入成功,并且在redo日志中記錄了commit標(biāo)記。事務(wù)提交完成后binlog日志和redo日志數(shù)據(jù)保持一致
- 數(shù)據(jù)持久化,IO線程不定期把BufferPool中的數(shù)據(jù)隨機寫入到磁盤,完成持久化
三、總結(jié)
MVCC實現(xiàn)機制(為什么同一個事務(wù)第一次查詢出來之后,就算其它事務(wù)把新數(shù)據(jù)修改了,當(dāng)前事務(wù)還是看到之前的數(shù)據(jù))
- 它內(nèi)部實際有個undo日志版本鏈,然后在事務(wù)第一次查詢的時候,它會生成一個read-view一致性視圖,然后我們后面所有查詢的數(shù)據(jù)都會根據(jù)我們的那個undo日志版本鏈去跟我們當(dāng)前的read-view里面按照一定的規(guī)則逐行去比對查找對應(yīng)的數(shù)據(jù)
BufferPool機制:
- 數(shù)據(jù)庫的增刪改查都是直接操作BufferPool的,當(dāng)我們執(zhí)行一條修改的SQL經(jīng)歷過Server層之后會調(diào)用具體的執(zhí)行引擎,然后將相關(guān)的數(shù)據(jù)頁加載到BufferPool中,修改前寫undo日志,記錄修改前的數(shù)據(jù)為了方便事務(wù)失敗之后的回滾,然后更新BufferPool,準(zhǔn)備提交事務(wù)寫redo日志保存操作記錄,因為如果MySQL宕機了會從redo日志中將數(shù)據(jù)恢復(fù)到BufferPool中,然后會寫binlog日志,保存操作記錄,因為當(dāng)我們刪除數(shù)據(jù)庫跑路時,binlog是用來恢復(fù)磁盤數(shù)據(jù)的,事務(wù)提交完成后,binlog日志寫入成功,并且在redo日志記錄提交標(biāo)記,此時redo日志和binlog日志數(shù)據(jù)一致,而redo日志采用順序IO寫入,這樣效率堪比內(nèi)存操作。對于數(shù)據(jù)持久化,InnoDB會有個后臺線程定時去將緩存刷到磁盤里
為什么MySQL不能直接更新磁盤上的數(shù)據(jù)而是設(shè)置了這么一套復(fù)雜的機制來執(zhí)行SQL
- 因為來一個請求直接對磁盤文件進行隨機讀寫,然后更新磁盤文件里的數(shù)據(jù)性能可能相當(dāng)差.
- 因為磁盤隨機讀寫的性能是非常差的,所以直接更新磁盤文件時不能讓數(shù)據(jù)庫抗住高并發(fā)的
- MySQL這套機制看起來很復(fù)雜,但它可以保證每個更新請求都是更新內(nèi)存BufferPool,然后順序?qū)懭罩疚募?,同時還能保證各種異常情況下的數(shù)據(jù)一致性
- 更新內(nèi)存的性能是極高的,然后順序?qū)懘疟P上的日志文件的性能也是非常高的,要遠高于隨機讀寫磁盤文件,正是通過這套機制,才能讓我們的MySQL數(shù)據(jù)庫在較高配置的機器上每秒可以抗下幾千甚至上完的讀寫請求
到此這篇關(guān)于深入理解MySQL中MVCC與BufferPool緩存機制的文章就介紹到這了,更多相關(guān)MVCC與BufferPool緩存機制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
mysql數(shù)據(jù)庫如何轉(zhuǎn)移到oracle
這篇文章主要介紹了mysql數(shù)據(jù)庫如何轉(zhuǎn)移到oracle,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-12-12MySQL數(shù)據(jù)庫常用操作技巧總結(jié)
這篇文章主要介紹了MySQL數(shù)據(jù)庫常用操作技巧,結(jié)合實例形式總結(jié)分析了mysql查詢、存儲過程、字符串截取、時間、排序等常用操作技巧,需要的朋友可以參考下2018-03-03MySQL專用服務(wù)器自動配置參數(shù)的實現(xiàn)
本文主要介紹了MySQL專用服務(wù)器自動配置參數(shù)的實現(xiàn),MySQL8.0推出了專用數(shù)據(jù)庫服務(wù)器自動配置參數(shù),通過打開innodb_dedicated_server,下面就來詳細的介紹一下,感興趣的可以了解一下2024-09-09