數(shù)據(jù)庫事務(wù)介紹
事務(wù)的四大特性（ACID）
原子性(atomicity)：?事務(wù)的最小工作單元均唉，要么全成功，要么全失敗。
一致性(consistency)：?事務(wù)開始和結(jié)束后辱挥，數(shù)據(jù)庫的完整性不會被破壞。
隔離性(isolation)：?不同事務(wù)之間互不影響边涕，四種隔離級別為RU（讀未提交）晤碘、RC（讀已提交）、RR（可重復(fù)讀）功蜓、SERIALIZABLE （串行化）园爷。
持久性(durability)：?事務(wù)提交后，對數(shù)據(jù)的修改是永久性的式撼，即使系統(tǒng)故障也不會丟失童社。
事務(wù)的隔離級別
讀未提交（Read UnCommitted/RU）
又稱為臟讀，一個事務(wù)可以讀取到另一個事務(wù)未提交的數(shù)據(jù)著隆。這種隔離級別歲最不安全的一種扰楼，因為未提交的事務(wù)是存在回滾的情況。
讀已提交（Read Committed/RC）
又稱為不可重復(fù)讀美浦，一個事務(wù)因為讀取到另一個事務(wù)已提交的修改數(shù)據(jù)弦赖，導(dǎo)致在當前事務(wù)的不同時間讀取同一條數(shù)據(jù)獲取的結(jié)果不一致。
舉個例子浦辨，在下面的例子中就會發(fā)現(xiàn)SessionA在一個事務(wù)期間兩次查詢的數(shù)據(jù)不一樣蹬竖。原因就是在于當前隔離級別為 RC，SessionA的事務(wù)可以讀取到SessionB提交的最新數(shù)據(jù)流酬。
發(fā)生時間SessionASessionB
1begin;
2select * from user where id=1;(張三)
3update user set name='李四' where id=1;(默認隱式提交事務(wù))
4select * from user where id=1;(李四)
5update user set name='王二' where id=1;(默認隱式提交事務(wù))
6select * from user where id=1;(王二)
可重復(fù)讀（Repeatable Read/RR）
又稱為幻讀案腺，一個事物讀可以讀取到其他事務(wù)提交的數(shù)據(jù)，但是在RR隔離級別下康吵，當前讀取此條數(shù)據(jù)只可讀取一次劈榨，在當前事務(wù)中，不論讀取多少次晦嵌，數(shù)據(jù)任然是第一次讀取的值同辣，不會因為在第一次讀取之后拷姿，其他事務(wù)再修改提交此數(shù)據(jù)而產(chǎn)生改變。因此也成為幻讀旱函，因為讀出來的數(shù)據(jù)并不一定就是最新的數(shù)據(jù)响巢。
舉個例子：在SessionA中第一次讀取數(shù)據(jù)時，后續(xù)其他事務(wù)修改提交數(shù)據(jù)棒妨，不會再影響到SessionA讀取的數(shù)據(jù)值踪古。此為可重復(fù)讀。
發(fā)生時間SessionASessionB
1begin;
2select * from user where id=1;(張三)
3update user set name='李四' where id=1; ?(默認隱式提交事務(wù))
4select * from user where id=1;(張三)
5update user set name='王二' where id=1;(默認隱式提交事務(wù))
6select * from user where id=1;(張三)
串行化（Serializable）
所有的數(shù)據(jù)庫的讀或者寫操作都為串行執(zhí)行券腔，當前隔離級別下只支持單個請求同時執(zhí)行伏穆，所有的操作都需要隊列執(zhí)行。所以種隔離級別下所有的數(shù)據(jù)是最穩(wěn)定的纷纫，但是性能也是最差的枕扫。數(shù)據(jù)庫的鎖實現(xiàn)就是這種隔離級別的更小粒度版本。
發(fā)生時間SessionASessionB
1begin;
2begin;
3update user set name='李四' where id=1;
4select * from user where id=1;(等待辱魁、wait)
5commit烟瞧；
6select * from user where id=1;(李四)
事務(wù)和MVCC原理
不同事務(wù)同時操作同一條數(shù)據(jù)產(chǎn)生的問題
示例：
發(fā)生時間SessionASessionB
1begin;
2begin;
3查詢余額 = 1000元
4查詢余額 = 1000元
5存入金額 100元，修改余額為 1100元
6取出現(xiàn)金100元染簇，此時修改余額為900元
8提交事務(wù)（余額=1100）
9提交事務(wù)（余額=900）
發(fā)生時間SessionASessionB
1begin;
2begin;
3查詢余額 = 1000元
4查詢余額 = 1000元
5存入金額 100元参滴，修改余額為 1100元
6取出現(xiàn)金100元，此時修改余額為900元
8提交事務(wù)（余額=1100）
9撤銷事務(wù)（余額恢復(fù)為1000元）
上面的兩種情況就是對于一條數(shù)據(jù)锻弓，多個事務(wù)同時操作可能會產(chǎn)生的問題卵洗，會出現(xiàn)某個事務(wù)的操作被覆蓋而導(dǎo)致數(shù)據(jù)丟失。
LBCC 解決數(shù)據(jù)丟失
LBCC弥咪，基于鎖的并發(fā)控制过蹂，Lock Based Concurrency Control。
使用鎖的機制聚至，在當前事務(wù)需要對數(shù)據(jù)修改時酷勺，將當前事務(wù)加上鎖，同一個時間只允許一條事務(wù)修改當前數(shù)據(jù)扳躬，其他事務(wù)必須等待鎖釋放之后才可以操作脆诉。
MVCC 解決數(shù)據(jù)丟失
MVCC，多版本的并發(fā)控制贷币，Multi-Version Concurrency Control击胜。
使用版本來控制并發(fā)情況下的數(shù)據(jù)問題，在B事務(wù)開始修改賬戶且事務(wù)未提交時役纹，當A事務(wù)需要讀取賬戶余額時偶摔，此時會讀取到B事務(wù)修改操作之前的賬戶余額的副本數(shù)據(jù)，但是如果A事務(wù)需要修改賬戶余額數(shù)據(jù)就必須要等待B事務(wù)提交事務(wù)促脉。
MVCC使得數(shù)據(jù)庫讀不會對數(shù)據(jù)加鎖辰斋，普通的SELECT請求不會加鎖策州，提高了數(shù)據(jù)庫的并發(fā)處理能力。借助MVCC宫仗，數(shù)據(jù)庫可以實現(xiàn)READ COMMITTED够挂，REPEATABLE READ等隔離級別，用戶可以查看當前數(shù)據(jù)的前一個或者前幾個歷史版本藕夫，保證了ACID中的I特性（隔離性)孽糖。
InnoDB的MVCC實現(xiàn)邏輯
InnoDB存儲引擎保存的MVCC的數(shù)據(jù)
InnoDB的MVCC是通過在每行記錄后面保存兩個隱藏的列來實現(xiàn)的。一個保存了行的事務(wù)ID（DB_TRX_ID）毅贮，一個保存了行的回滾指針（DB_ROLL_PT）办悟。每開始一個新的事務(wù)，都會自動遞增產(chǎn) 生一個新的事務(wù)id嫩码。事務(wù)開始時刻的會把事務(wù)id放到當前事務(wù)影響的行事務(wù)id中，當查詢時需要用當前事務(wù)id和每行記錄的事務(wù)id進行比較罪既。
下面看一下在REPEATABLE READ隔離級別下铸题，MVCC具體是如何操作的。
SELECT
InnoDB 會根據(jù)以下兩個條件檢查每行記錄：
InnoDB只查找版本早于當前事務(wù)版本的數(shù)據(jù)行（也就是琢感，行的事務(wù)編號小于或等于當前事務(wù)的事務(wù)編號）丢间，這樣可以確保事務(wù)讀取的行，要么是在事務(wù)開始前已經(jīng)存在的驹针，要么是事務(wù)自身插入或者修改過的烘挫。
刪除的行要事務(wù)ID判斷，讀取到事務(wù)開始之前狀態(tài)的版本柬甥，只有符合上述兩個條件的記錄饮六，才能返回作為查詢結(jié)果。
INSERT
InnoDB為新插入的每一行保存當前事務(wù)編號作為行版本號苛蒲。
DELETE
InnoDB為刪除的每一行保存當前事務(wù)編號作為行刪除標識卤橄。
UPDATE
InnoDB為插入一行新記錄，保存當前事務(wù)編號作為行版本號臂外，同時保存當前事務(wù)編號到原來的行作為行刪除標識窟扑。
保存這兩個額外事務(wù)編號，使大多數(shù)讀操作都可以不用加鎖漏健。這樣設(shè)計使得讀數(shù)據(jù)操作很簡單嚎货，性能很好，并且也能保證只會讀取到符合標準的行蔫浆。不足之處是每行記錄都需要額外的存儲空間殖属，需要做更多的行檢查工作，以及一些額外的維護工作瓦盛。
MVCC只在REPEATABLE READ和READ COMMITIED兩個隔離級別下工作忱辅。其他兩個隔離級別都和 MVCC不兼容 七蜘，因為READ UNCOMMITIED總是讀取最新的數(shù)據(jù)行，而不是符合當前事務(wù)版本的數(shù)據(jù)行墙懂。而SERIALIZABLE則會對所有讀取的行都加鎖橡卤。
MVCC 在mysql 中的實現(xiàn)依賴的是 undo log 與 read view 。
undo log
根據(jù)行為的不同损搬，undo log分為兩種：insert undo log?和?update undo log
insert undo log：
insert 操作中產(chǎn)生的undo log碧库，因為insert操作記錄只對當前事務(wù)本身課件，對于其他事務(wù)此記錄不可見巧勤，所以 insert undo log 可以在事務(wù)提交后直接刪除而不需要進行purge操作嵌灰。
purge的主要任務(wù)是將數(shù)據(jù)庫中已經(jīng) mark del 的數(shù)據(jù)刪除，另外也會批量回收undo pages
數(shù)據(jù)庫 Insert時的數(shù)據(jù)初始狀態(tài)：
update undo log：
update 或 delete 操作中產(chǎn)生的 undo log颅悉。因為會對已經(jīng)存在的記錄產(chǎn)生影響沽瞭，為了提供 MVCC機制，因此update undo log 不能在事務(wù)提交時就進行刪除剩瓶，而是將事務(wù)提交時放到入 history list 上驹溃，等待 purge 線程進行最后的刪除操作。
數(shù)據(jù)第一次被修改時：
當另一個事務(wù)第二次修改當前數(shù)據(jù)：
為了保證事務(wù)并發(fā)操作時延曙，在寫各自的undo log時不產(chǎn)生沖突豌鹤，InnoDB采用回滾段的方式來維護undo log的并發(fā)寫入和持久化≈Φ蓿回滾段實際上是一種 Undo 文件組織方式布疙。
ReadView
對于?RU(READ UNCOMMITTED)?隔離級別下，所有事務(wù)直接讀取數(shù)據(jù)庫的最新值即可愿卸，和?SERIALIZABLE?隔離級別灵临，所有請求都會加鎖，同步執(zhí)行趴荸。所以這對這兩種情況下是不需要使用到?Read View?的版本控制俱诸。
對于?RC(READ COMMITTED)?和?RR(REPEATABLE READ)?隔離級別的實現(xiàn)就是通過上面的版本控制來完成。兩種隔離界別下的核心處理邏輯就是判斷所有版本中哪個版本是當前事務(wù)可見的處理赊舶。針對這個問題InnoDB在設(shè)計上增加了ReadView的設(shè)計睁搭，ReadView中主要包含當前系統(tǒng)中還有哪些活躍的讀寫事務(wù)，把它們的事務(wù)id放到一個列表中笼平，我們把這個列表命名為為m_ids园骆。
對于查詢時的版本鏈數(shù)據(jù)是否看見的判斷邏輯：
如果被訪問版本的 trx_id 屬性值小于 m_ids 列表中最小的事務(wù)id，表明生成該版本的事務(wù)在生成 ReadView 前已經(jīng)提交寓调，所以該版本可以被當前事務(wù)訪問锌唾。
如果被訪問版本的 trx_id 屬性值大于 m_ids 列表中最大的事務(wù)id，表明生成該版本的事務(wù)在生成 ReadView 后才生成，所以該版本不可以被當前事務(wù)訪問晌涕。
如果被訪問版本的 trx_id 屬性值在 m_ids 列表中最大的事務(wù)id和最小事務(wù)id之間滋捶，那就需要判斷一下 trx_id 屬性值是不是在 m_ids 列表中，如果在余黎，說明創(chuàng)建 ReadView 時生成該版本的事務(wù)還是活躍的重窟，該版本不可以被訪問；如果不在惧财，說明創(chuàng)建 ReadView 時生成該版本的事務(wù)已經(jīng)被提交巡扇，該版本可以被訪問。
舉個例子：
READ COMMITTED 隔離級別下的ReadView
每次讀取數(shù)據(jù)前都生成一個ReadView (m_ids列表)
時間Transaction 777Transaction 888Trasaction 999
T1begin;
T2begin;begin垮衷；
T3UPDATE user SET name = 'CR7' WHERE id = 1;
T4...
T5UPDATE user SET name = 'Messi' WHERE id = 1;SELECT * FROM user where id = 1;
T6commit;
T7UPDATE user SET name = 'Neymar' WHERE id = 1;
T8SELECT * FROM user where id = 1;
T9UPDATE user ?SET name = 'Dybala' WHERE id = 1;
T10commit;
T11SELECT * FROM user where id = 1;
這里分析下上面的情況下的ReadView
時間點 T5 情況下的 SELECT 語句：
當前時間點的版本鏈：
此時 SELECT 語句執(zhí)行厅翔，當前數(shù)據(jù)的版本鏈如上，因為當前的事務(wù)777搀突，和事務(wù)888 都未提交刀闷，所以此時的活躍事務(wù)的ReadView的列表情況?m_ids：[777, 888]?，因此查詢語句會根據(jù)當前版本鏈中小于?m_ids?中的最大的版本數(shù)據(jù)仰迁，即查詢到的是 Mbappe甸昏。
時間點 T8 情況下的 SELECT 語句：
當前時間的版本鏈情況：
此時 SELECT 語句執(zhí)行，當前數(shù)據(jù)的版本鏈如上轩勘，因為當前的事務(wù)777已經(jīng)提交筒扒，和事務(wù)888 未提交怯邪，所以此時的活躍事務(wù)的ReadView的列表情況?m_ids：[888]?绊寻，因此查詢語句會根據(jù)當前版本鏈中小于?m_ids?中的最大的版本數(shù)據(jù)，即查詢到的是 Messi悬秉。
時間點 T11 情況下的 SELECT 語句：
當前時間點的版本鏈信息：
此時 SELECT 語句執(zhí)行澄步，當前數(shù)據(jù)的版本鏈如上，因為當前的事務(wù)777和事務(wù)888 都已經(jīng)提交和泌，所以此時的活躍事務(wù)的ReadView的列表為空 村缸，因此查詢語句會直接查詢當前數(shù)據(jù)庫最新數(shù)據(jù)，即查詢到的是 Dybala武氓。
總結(jié)：?使用READ COMMITTED隔離級別的事務(wù)在每次查詢開始時都會生成一個獨立的 ReadView梯皿。
REPEATABLE READ 隔離級別下的ReadView
在事務(wù)開始后第一次讀取數(shù)據(jù)時生成一個ReadView（m_ids列表）
時間Transaction 777Transaction 888Trasaction 999
T1begin;
T2begin;begin；
T3UPDATE user SET name = 'CR7' WHERE id = 1;
T4...
T5UPDATE user SET name = 'Messi' WHERE id = 1;SELECT * FROM user where id = 1;
T6commit;
T7UPDATE user SET name = 'Neymar' WHERE id = 1;
T8SELECT * FROM user where id = 1;
T9UPDATE user ?SET name = 'Dybala' WHERE id = 1;
T10commit;
T11SELECT * FROM user where id = 1;
時間點 T5 情況下的 SELECT 語句：
當前版本鏈：
再當前執(zhí)行select語句時生成一個ReadView县恕，此時?m_ids?內(nèi)容是：[777,888]东羹，所以但前根據(jù)ReadView可見版本查詢到的數(shù)據(jù)為 Mbappe。
時間點 T8 情況下的 SELECT 語句：
當前的版本鏈：
此時在當前的 Transaction 999 的事務(wù)里忠烛。由于T5的時間點已經(jīng)生成了ReadView属提，所以再當前的事務(wù)中只會生成一次ReadView，所以此時依然沿用T5時的m_ids：[777,999]，所以此時查詢數(shù)據(jù)依然是 Mbappe冤议。
時間點 T11 情況下的 SELECT 語句：
當前的版本鏈：
此時情況跟T8完全一樣斟薇。由于T5的時間點已經(jīng)生成了ReadView，所以再當前的事務(wù)中只會生成一次ReadView恕酸，所以此時依然沿用T5時的m_ids：[777,999]堪滨，所以此時查詢數(shù)據(jù)依然是 Mbappe。
MVCC總結(jié)：
所謂的MVCC（Multi-Version Concurrency Control 尸疆，多版本并發(fā)控制）指的就是在使用?READ COMMITTD?椿猎、REPEATABLE READ?這兩種隔離級別的事務(wù)在執(zhí)行普通的 SEELCT 操作時訪問記錄的版本鏈的過程，這樣子可以使不同事務(wù)的?讀-寫?寿弱、?寫-讀?操作并發(fā)執(zhí)行犯眠，從而提升系統(tǒng)性能。
在 MySQL 中症革， READ COMMITTED 和 REPEATABLE READ 隔離級別的的一個非常大的區(qū)別就是它們生成 ReadView 的時機不同筐咧。在 READ COMMITTED 中每次查詢都會生成一個實時的 ReadView，做到保證每次提交后的數(shù)據(jù)是處于當前的可見狀態(tài)噪矛。而 REPEATABLE READ 中量蕊，在當前事務(wù)第一次查詢時生成當前的 ReadView，并且當前的 ReadView 會一直沿用到當前事務(wù)提交艇挨，以此來保證可重復(fù)讀（REPEATABLE READ）残炮。
