一、MVCC機(jī)制

• MVCC(Multi Version Concurrency Control)，MySQL(默認(rèn))RR隔離級(jí)別就是通過(guò)該機(jī)制來(lái)保證的，對(duì)一行數(shù)據(jù)的讀與寫(xiě)兩個(gè)操作默認(rèn)是不會(huì)通過(guò)加鎖互斥來(lái)保證隔離性的
• 串行化隔離級(jí)別是為了保證較高的隔離性，是通過(guò)將所有操作加鎖互斥來(lái)實(shí)現(xiàn)的
• MySQL在RC隔離級(jí)別和RR隔離級(jí)別下都實(shí)現(xiàn)了MVCC機(jī)制
• RC每次查詢(xún)都會(huì)創(chuàng)建一個(gè)reade-view，而RR在創(chuàng)建完read-view之后，在不提交事務(wù)之前，每次查詢(xún)還是第一次創(chuàng)建的read-view

undo日志版本鏈與read-view機(jī)制

• undo日志版本鏈?zhǔn)侵敢恍袛?shù)據(jù)被多個(gè)事務(wù)一次修改后，當(dāng)每個(gè)事務(wù)修改完之后，MySQL會(huì)保留修改前的數(shù)據(jù)undo回滾日志，并且用兩個(gè)隱藏字段trx_id和roll_pointer把只寫(xiě)undo日志串聯(lián)起來(lái)形成一個(gè)歷史記錄版本鏈.
• RR隔離級(jí)別，當(dāng)事務(wù)開(kāi)啟，執(zhí)行任何SQL時(shí)會(huì)生成當(dāng)前事務(wù)的read-view一致性視圖，該視圖在事務(wù)結(jié)束之前都不會(huì)變化(如果是RC隔離界別在每次執(zhí)行查詢(xún)SQL時(shí)都會(huì)重新生成最新的read-view)，這個(gè)視圖由執(zhí)行查詢(xún)時(shí)所有未提交的事務(wù)id數(shù)組(數(shù)組里最小的id為min_id)和已創(chuàng)建的最大事務(wù)id(max_id)組成，事務(wù)里任何SQL查詢(xún)結(jié)果需要從對(duì)應(yīng)版本鏈里的最新數(shù)據(jù)開(kāi)始逐條跟read-view作比對(duì)，從而得到最終的結(jié)果

版本鏈比對(duì)規(guī)則

• 如果row的trx_id落在綠色部分(trx < min_id)，表示這個(gè)版本是已提交的事務(wù)生成的，這個(gè)數(shù)據(jù)是可見(jiàn)的
• 如果row的trx_id落在紅色部分(trx > max_id)，表示這個(gè)版本是由將來(lái)啟動(dòng)的(未開(kāi)始)事務(wù)生成的，是不可見(jiàn)的(若row的trx_id就是當(dāng)前自己的事務(wù)是可見(jiàn)的)
• 如果 row 的 trx_id 落在黃色部分(min_id <= trx_id <= max_id),那就包括兩種情況
  • 若 row 的 trx_id 在視圖數(shù)組中，表示這個(gè)版本是由還沒(méi)提交的事務(wù)生成的不可見(jiàn)(若 row 的 trx_id 就是當(dāng)前自己的事務(wù)是可見(jiàn)的)
  • 若 row 的 trx_id 不在視圖數(shù)組中，表示這個(gè)版本是已經(jīng)提交了的事務(wù)生成的可見(jiàn)

二、BufferPool機(jī)制

InnoDB執(zhí)行的BufferPool緩存機(jī)制：

InnoDB的SQL執(zhí)行流程：

• 當(dāng)客戶(hù)端執(zhí)行一條修改的SQL，需要經(jīng)過(guò)Server層，再調(diào)用具體的執(zhí)行引擎
• 加載數(shù)據(jù)頁(yè)，把需要修改數(shù)據(jù)所在的數(shù)據(jù)頁(yè)，緩存到BufferPool
• 修改前寫(xiě)undo日志，記錄更改前數(shù)據(jù)，如果事務(wù)執(zhí)行失敗，使用undo日志進(jìn)行數(shù)據(jù)回滾
• 更新BufferPool中的數(shù)據(jù)
• 準(zhǔn)備提交事務(wù)寫(xiě)redo日志，保存操作記錄。redo日志用來(lái)恢復(fù)已提交事務(wù)的BufferPool
• 準(zhǔn)備提交事務(wù)寫(xiě)binlog日志，保存操作記錄。binlog日志用來(lái)恢復(fù)磁盤(pán)數(shù)據(jù)
• 事務(wù)提交完成，此時(shí)binlog日志寫(xiě)入成功，并且在redo日志中記錄了commit標(biāo)記。事務(wù)提交完成后binlog日志和redo日志數(shù)據(jù)保持一致
• 數(shù)據(jù)持久化，IO線程不定期把BufferPool中的數(shù)據(jù)隨機(jī)寫(xiě)入到磁盤(pán)，完成持久化

三、總結(jié)

MVCC實(shí)現(xiàn)機(jī)制(為什么同一個(gè)事務(wù)第一次查詢(xún)出來(lái)之后，就算其它事務(wù)把新數(shù)據(jù)修改了，當(dāng)前事務(wù)還是看到之前的數(shù)據(jù))

• 它內(nèi)部實(shí)際有個(gè)undo日志版本鏈，然后在事務(wù)第一次查詢(xún)的時(shí)候，它會(huì)生成一個(gè)read-view一致性視圖，然后我們后面所有查詢(xún)的數(shù)據(jù)都會(huì)根據(jù)我們的那個(gè)undo日志版本鏈去跟我們當(dāng)前的read-view里面按照一定的規(guī)則逐行去比對(duì)查找對(duì)應(yīng)的數(shù)據(jù)

BufferPool機(jī)制：

• 數(shù)據(jù)庫(kù)的增刪改查都是直接操作BufferPool的，當(dāng)我們執(zhí)行一條修改的SQL經(jīng)歷過(guò)Server層之后會(huì)調(diào)用具體的執(zhí)行引擎，然后將相關(guān)的數(shù)據(jù)頁(yè)加載到BufferPool中，修改前寫(xiě)undo日志，記錄修改前的數(shù)據(jù)為了方便事務(wù)失敗之后的回滾，然后更新BufferPool，準(zhǔn)備提交事務(wù)寫(xiě)redo日志保存操作記錄，因?yàn)槿绻鸐ySQL宕機(jī)了會(huì)從redo日志中將數(shù)據(jù)恢復(fù)到BufferPool中，然后會(huì)寫(xiě)binlog日志，保存操作記錄，因?yàn)楫?dāng)我們刪除數(shù)據(jù)庫(kù)跑路時(shí)，binlog是用來(lái)恢復(fù)磁盤(pán)數(shù)據(jù)的，事務(wù)提交完成后，binlog日志寫(xiě)入成功，并且在redo日志記錄提交標(biāo)記，此時(shí)redo日志和binlog日志數(shù)據(jù)一致，而redo日志采用順序IO寫(xiě)入，這樣效率堪比內(nèi)存操作。對(duì)于數(shù)據(jù)持久化，InnoDB會(huì)有個(gè)后臺(tái)線程定時(shí)去將緩存刷到磁盤(pán)里

為什么MySQL不能直接更新磁盤(pán)上的數(shù)據(jù)而是設(shè)置了這么一套復(fù)雜的機(jī)制來(lái)執(zhí)行SQL

• 因?yàn)閬?lái)一個(gè)請(qǐng)求直接對(duì)磁盤(pán)文件進(jìn)行隨機(jī)讀寫(xiě)，然后更新磁盤(pán)文件里的數(shù)據(jù)性能可能相當(dāng)差.
• 因?yàn)?strong>磁盤(pán)隨機(jī)讀寫(xiě)的性能是非常差的，所以直接更新磁盤(pán)文件時(shí)不能讓數(shù)據(jù)庫(kù)抗住高并發(fā)的
• MySQL這套機(jī)制看起來(lái)很復(fù)雜，但它可以保證每個(gè)更新請(qǐng)求都是更新內(nèi)存BufferPool，然后順序?qū)懭罩疚募?，同時(shí)還能保證各種異常情況下的數(shù)據(jù)一致性
• 更新內(nèi)存的性能是極高的，然后順序?qū)懘疟P(pán)上的日志文件的性能也是非常高的,要遠(yuǎn)高于隨機(jī)讀寫(xiě)磁盤(pán)文件，正是通過(guò)這套機(jī)制，才能讓我們的MySQL數(shù)據(jù)庫(kù)在較高配置的機(jī)器上每秒可以抗下幾千甚至上完的讀寫(xiě)請(qǐng)求

到此這篇關(guān)于深入理解MySQL中MVCC與BufferPool緩存機(jī)制的文章就介紹到這了,更多相關(guān)MVCC與BufferPool緩存機(jī)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論