1. 事務(wù)

介紹MVCC之前，先介紹下事務(wù)：事務(wù)是為了保證數(shù)據(jù)庫中數(shù)據(jù)的完整性和一致性。

事務(wù)的4個(gè)基本要素：

• 原子性（Atomicity）：要么同時(shí)成功，要么同時(shí)失敗。（通過undo log回滾日志實(shí)現(xiàn)）
• 一致性（Consistency）：一方扣款 xxx 元，另一方收款 xxx 元，符合事物發(fā)展的正常邏輯（通過lock鎖實(shí)現(xiàn)）
• 隔離性（Isolation）：此時(shí)有多個(gè)類似 扣款/收款 事件同時(shí)發(fā)生，每個(gè)事件之間是相互獨(dú)立的（通過 lock鎖 + MVCC實(shí)現(xiàn)）
• 持久性（Durability）：不管數(shù)據(jù)庫宕機(jī)或重啟，數(shù)據(jù)最終都落到了磁盤上，下次加載依然可見 （通過 redo log實(shí)現(xiàn)）

2. MVCC初探

目的：主要是為了 提高數(shù)據(jù)庫并發(fā)性能。用更好的方式去處理 讀/寫 沖突，做到即使有 讀/寫 沖突時(shí)，也能做到不加鎖，非阻塞并發(fā)讀。

不同隔離級別下，可能引發(fā)的問題： 臟讀：并發(fā)情況下，一方事務(wù)讀到了另一方事務(wù) “已 update 但未 commit” 的數(shù)據(jù)，破壞了事務(wù)隔離性。不可重復(fù)讀：并發(fā)情況下，一方事務(wù)讀到了另一方事務(wù) “已 update 或 delete ，并 commit ” 的數(shù)據(jù)，破壞了事務(wù)隔離性。幻讀：并發(fā)情況下，一方事務(wù)讀到了另一方事務(wù)" insert 并 commit "的數(shù)據(jù)，導(dǎo)致前后讀取結(jié)果不一致。

MVCC中的四種事務(wù)隔離級別：

提問：V1、V2、V3在不同事務(wù)隔離級別下讀取到的值分別是：

• RU-讀未提交 級別：20、20、20（可能發(fā)生：臟讀、不可重復(fù)讀）
• RC-讀已提交 級別：18、20、20（不可能發(fā)生：臟讀、可能發(fā)生：不可重復(fù)度）
• RR-可重復(fù)讀 級別：18、18、20 （不可能發(fā)生：臟讀、不可重復(fù)讀；但是因?yàn)槭聞?wù)A已提交，所以V3再次查詢時(shí)跟事務(wù)A是沒有隔離性的要求的，因此V3讀取到的是20）

3. LBCC & MVCC

•  LBCC（Lock-Base Concurrency Control）基于鎖的并發(fā)控制；
• MVCC（Multiversion Concurrency Control）多版本并發(fā)控制；

LBCC 鎖相關(guān)：

MySQL 5.5 版本之前，默認(rèn)的存儲引擎是MyISAM，5.5之后默認(rèn)引擎是Innodb。Innodb支持事務(wù)，包括：行鎖/表鎖，MyISAM不支持。 意向鎖 意向共享鎖/讀鎖（表鎖類型，無法手動創(chuàng)建），mysql 中語法： lock in share mode意向排它鎖/寫鎖（表鎖類型，無法手動創(chuàng)建），mysql 中語法： for update

常見問題：為什么要加入意向鎖？

意向鎖并不是真正用來鎖定數(shù)據(jù)的，而是用來告訴你當(dāng)前表中是否已經(jīng)有了被 共享鎖/排它鎖
鎖定的數(shù)據(jù)行。如果有就沒必要再去加無用的表鎖了，起到一個(gè)標(biāo)識作用，提高加表鎖的效率（相當(dāng)于高鐵洗手間門上方是否有人正在使用的 “指示燈”）。

記錄鎖（Record Lock）、間隙鎖（Gap Lock）、臨鍵鎖（Next-Key Lock）：

• 介紹：臨鍵鎖 = 記錄鎖 + 間隙鎖，是 RR 可重復(fù)讀-隔離級別下獨(dú)有的，
• 目的：間隙鎖的出現(xiàn)就是為了解決可重復(fù)讀隔離級別下的幻讀問題

問題：如圖示：執(zhí)行此sql語句（先開啟事務(wù)）：BEGIN; SELECT * FROM tbl WHERE id > 15 FOR UPDATE; ，以下兩個(gè)sql語句可以執(zhí)行成功嗎？

MVCC底層實(shí)現(xiàn)詳解：

快照讀（實(shí)際上為讀相關(guān)的操作）：讀取的是記錄的可見版本 (有可能是歷史版本)，不用加鎖。

簡單的 SELECT 操作，屬于快照讀，不加鎖。

SELECT * FROM user WHERE ? 

當(dāng)前讀（實(shí)際上為寫相關(guān)的操作）：在事務(wù)中，update 數(shù)據(jù)前，還要去MySQL中重新讀取一遍該數(shù)據(jù)對應(yīng)最新版本的記錄，并且 當(dāng)前讀 返回的記錄都會加上鎖，保證其他事務(wù)不會再并發(fā)修改這條記錄。以下兩種方式都屬于當(dāng)前讀，需要加鎖：

• 特殊讀 (加鎖讀): SELECT * FROM user WHERE id = xxx LOCK IN SHARE MODE;
• INSERT / UPDATE / DELETE 等寫操作。

問題：在 RR-可重復(fù)讀 的默認(rèn)隔離級別下，假設(shè)起始的age為18，那么Q1和Q2對應(yīng)的age分別是多少呢？

• 針對 “事務(wù)B” 分析：因?yàn)榇嬖?UPDATE 寫操作，觸發(fā)了 當(dāng)前讀，所以要先去讀最新提交的版本號記錄（即：事務(wù)C UPDATE 后提交的記錄），然后事務(wù)B再去執(zhí)行自己的 UPDATE 操作。也就是要先去讀事務(wù)C提交的最新數(shù)據(jù)為19，然后事務(wù)B自身再 UPDATE 加1最終變?yōu)?0。
• 針對 “事務(wù)A” 分析：因?yàn)槭聞?wù)A本身是沒有任何的寫操作，僅僅是 SELECT 查詢操作，觸發(fā) 快照讀。所以事務(wù)A只認(rèn)準(zhǔn)事務(wù) BEGIN 開始之前記錄的 最新最后提交的版本號，其記錄值也就是初始的18。

• BEGIN 事務(wù)開始的時(shí)候會創(chuàng)建一個(gè)快照，并為對應(yīng)事務(wù)分配一個(gè)事務(wù)id，即 TRX_ID
• 開啟事務(wù)之前最后的版本號為：up_limit_id=999，對應(yīng) age=18
• 事務(wù)B和事務(wù)C都有 UPDATE 操作（當(dāng)前讀），所以 row_trx_id 為自身的 TRX_ID 的值，分別是1001和1002。而事務(wù)A沒有 UPDATE 操作（快照讀），所以只認(rèn)準(zhǔn)事務(wù)A在 事務(wù)開始前 最后的版本號 up_limit_id=999，其 age=18。

總結(jié)

• 事務(wù)：是為了保證數(shù)據(jù)庫中數(shù)據(jù)的完整性和一致性。事務(wù)的4個(gè)特性：ACID。
• MVCC的好處：提高數(shù)據(jù)庫并發(fā)性能。用更好的方式去處理 讀/寫 沖突，做到即使有 讀/寫 沖突時(shí)，也能做到不加鎖，非阻塞并發(fā)讀。
• MVCC四種隔離級別 ：讀未提交、讀已提交、可重復(fù)讀（MySQL默認(rèn)級別）、串行化。
• MVCC事務(wù)隔離級別中，常見的三種問題：臟讀、幻讀、不可重復(fù)讀。在RR的默認(rèn)隔離級別下，單純的 SELECT 只觸發(fā) “快照讀” 。而當(dāng)你包含 INSERT / UPDATE / DELETE 等 寫操作 時(shí)，這時(shí)就會觸發(fā) 當(dāng)前讀，也就是在事務(wù)中，在相關(guān)寫操作之前會再去讀取一次其他事務(wù)的最后提交記錄。這里的關(guān)鍵在于你事務(wù)中的sql是單純的 SELECT 語句（快照讀），還是你事務(wù)在的sql是包含了INSERT / UPDATE / DELETE 等 寫操作（當(dāng)前讀）。
• 沒有建立索引或索引失效，行鎖會升級為表鎖，因?yàn)檎也坏綄?yīng)行記錄。所以為了避免兩個(gè)事務(wù)同時(shí)修改一張表的不同記錄會導(dǎo)致表鎖的問題，建議加上索引，這樣就只是行鎖，而不會升級為表鎖！
• 幻讀的解決關(guān)鍵在于 間隙鎖 和 臨鍵鎖（臨鍵鎖 = 記錄鎖 + 間隙鎖） 。

最后，補(bǔ)充一個(gè)問題點(diǎn)：

如果不聲明的創(chuàng)建主鍵，會有哪些危害？ 比如你的id（假設(shè)int類型）沒有聲明為主鍵，并且也沒有聲明唯一索引（當(dāng)未聲明主鍵時(shí)，唯一索引會被取代為主鍵）

• 行鎖升級為表鎖
• 當(dāng)數(shù)據(jù)量達(dá)到頂峰的時(shí)候，可能會造成“主鍵沖突”，int的取值范圍為2^32 -1，當(dāng)未聲明主鍵時(shí)，達(dá)到最大值范圍時(shí)，id會再次重新從0開使自增，這時(shí)候可能會出現(xiàn)覆蓋之前row_id記錄的情況，造成數(shù)據(jù)丟失。相反的，如果聲明主鍵的話，那么當(dāng)id達(dá)到上限時(shí)，再次insert時(shí)會報(bào)“主鍵沖突”錯(cuò)誤，這時(shí)候可以將之前的int 類型的id改為big int。
• MySQL會自動聲明一個(gè)“隱藏主鍵 row_id”，占6字節(jié)。而你自己聲明int類型的主鍵時(shí)，只會消耗4字節(jié)。因此這是一種資源的浪費(fèi)！

到此這篇關(guān)于MySQL中 LBCC 和 MVCC 的理解及常見問題示例的文章就介紹到這了,更多相關(guān)MySQL中LBCC和 MVCC內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論