一、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之后，在不提交事務之前，每次查詢還是第一次創(chuàng)建的read-view

undo日志版本鏈與read-view機制

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

版本鏈比對規(guī)則

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

二、BufferPool機制

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

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

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

三、總結

MVCC實現(xiàn)機制(為什么同一個事務第一次查詢出來之后，就算其它事務把新數(shù)據(jù)修改了，當前事務還是看到之前的數(shù)據(jù))

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

BufferPool機制：

• 數(shù)據(jù)庫的增刪改查都是直接操作BufferPool的，當我們執(zhí)行一條修改的SQL經(jīng)歷過Server層之后會調用具體的執(zhí)行引擎，然后將相關的數(shù)據(jù)頁加載到BufferPool中，修改前寫undo日志，記錄修改前的數(shù)據(jù)為了方便事務失敗之后的回滾，然后更新BufferPool，準備提交事務寫redo日志保存操作記錄，因為如果MySQL宕機了會從redo日志中將數(shù)據(jù)恢復到BufferPool中，然后會寫binlog日志，保存操作記錄，因為當我們刪除數(shù)據(jù)庫跑路時，binlog是用來恢復磁盤數(shù)據(jù)的，事務提交完成后，binlog日志寫入成功，并且在redo日志記錄提交標記，此時redo日志和binlog日志數(shù)據(jù)一致，而redo日志采用順序IO寫入，這樣效率堪比內存操作。對于數(shù)據(jù)持久化，InnoDB會有個后臺線程定時去將緩存刷到磁盤里

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

• 因為來一個請求直接對磁盤文件進行隨機讀寫，然后更新磁盤文件里的數(shù)據(jù)性能可能相當差.
• 因為磁盤隨機讀寫的性能是非常差的，所以直接更新磁盤文件時不能讓數(shù)據(jù)庫抗住高并發(fā)的
• MySQL這套機制看起來很復雜，但它可以保證每個更新請求都是更新內存BufferPool，然后順序寫日志文件，同時還能保證各種異常情況下的數(shù)據(jù)一致性
• 更新內存的性能是極高的，然后順序寫磁盤上的日志文件的性能也是非常高的,要遠高于隨機讀寫磁盤文件，正是通過這套機制，才能讓我們的MySQL數(shù)據(jù)庫在較高配置的機器上每秒可以抗下幾千甚至上完的讀寫請求

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

最新評論