原文來自極客時間,?第八講:事務(wù)隔離[mysql實戰(zhàn)45講]

圖1

一:總括:?

? ? 1. begin / start transaction 并不是事務(wù)起點, 而是他們之后的第一個操作innodb表的語句.?

? ? 2. 馬上啟動事務(wù) : start transaction with consistent snapshot

? ? 3. 事務(wù)A看的到k 是1;? 因為一致性視圖在start transaction whit consistent snapshot時創(chuàng)建;?

? ? 4. 事務(wù)B看到的k 是 2:? 因為 事務(wù)C是最先提交的, update有排他鎖, 所以事務(wù)B的update 和事務(wù)CD的update沖突了,? ==> 有疑問!??

二: "快照"在MVCC中是怎么工作的 ?

1.疑問: 什么是MVCC ?? ? ?==>?Multi-Version Concurrency Control 多版本并發(fā)控制

? ? 1: MVCC步驟:?

? ? ? ? 1.事務(wù)啟動時, 創(chuàng)建快照; 基于整個庫

? ? ? ? ? ? ? ? 唯一的事務(wù)id ==> transaction id

? ? ? ? ? ? ? ? 數(shù)據(jù)版本的事務(wù)ID ==> row trx_id

2.行狀態(tài)變更圖

名詞解釋:?

1.事務(wù)ID : 唯一的, 遞增的

2.一致性視圖數(shù)組 read - view : 保存事務(wù)啟動瞬間"活躍"的事務(wù)ID, 由高水位, 低水位組成.?

3.活躍: 啟動但未提交

4: 低水位: 數(shù)組中事務(wù)ID最小值

5: 高水位: 當(dāng)前系統(tǒng)創(chuàng)建過的事務(wù)ID最大值

? ? 注意: 獲取視圖數(shù)組高低水位, 是原子操作,期間不能創(chuàng)建新事務(wù).

3.數(shù)據(jù)版本可見性規(guī)則

6:row trx_id: 行數(shù)據(jù)版本, 哪個事務(wù)更新了該行,則把事務(wù)ID賦給row trx_id

? ? ==> 既: row trx_id? =? 最新更新該行的事務(wù)ID

7.數(shù)據(jù)版本的可見性規(guī)則: read - view 和 row trx_id 對比得出.

疑問1: 3.b的具體場景是什么樣的? ==> 圖3畫的不對.?

總結(jié)1 事務(wù)視圖(一致性讀) :?

? ? 1. 版本未提交, 不可見.?

? ? 2. 版本已提交, 但是在視圖創(chuàng)建后提交的, 不可見;

? ? 3. 版本已提交, 是在視圖創(chuàng)建前提交的, 可見.

? ? 4.自己的更新, 可見.?

4. 事務(wù)A查詢數(shù)據(jù)邏輯圖

總結(jié)2: select 是一致性讀:?

三: 更新邏輯

事務(wù)B更新邏輯

????規(guī)則1: 更新數(shù)據(jù)都是先讀后寫, 這個讀就是當(dāng)前讀 current read

????適用范圍: update 語句 ,? 加鎖的select 語句

6.事務(wù)C不是馬上提交

? ? 推導(dǎo)1 : 如果事務(wù)C不馬上提交, 則需要用到兩階段鎖協(xié)議, 事務(wù)B的update 和select 會被阻塞.

????總結(jié)3:update 是當(dāng)前讀.?

疑問2: 那insert? 和delete 呢 ??

7. 事務(wù)B更新邏輯圖

????結(jié)論4: 可重復(fù)讀的核心是一致性讀 consistent read

四: 可重復(fù)讀 和 讀提交的區(qū)別:?

? ? 可重復(fù)讀: 事務(wù)開始時創(chuàng)建一致性視圖;

? ? 讀提交: 每一個語句執(zhí)行前,重新算一個新視圖.?

? ? ==> 推論: 讀提交級別下, 都是當(dāng)前讀.??

? ? ? ? ? ? 注意: 當(dāng)前讀也需要遵守兩階段鎖協(xié)議? ??