事務(wù)的四大特性(簡稱ACID)

數(shù)據(jù)庫如果支持事務(wù)的操作，那么就具備以下四個(gè)特性：

1揭朝、原子性(Atomicity)

• 事務(wù)是數(shù)據(jù)庫的邏輯工作單位队贱，事務(wù)中包括的諸操作要么全做色冀，要么全不做。

2柱嫌、一致性(Consistency)

• 事務(wù)執(zhí)行的結(jié)果必須是使數(shù)據(jù)庫從一個(gè)一致性狀態(tài)變到另一個(gè)一致性狀態(tài)锋恬。一致性與原子性是密切相關(guān)的。

3编丘、隔離性(Isolation)

• 一個(gè)事務(wù)的執(zhí)行不能被其他事務(wù)干擾与学。

4、持續(xù)性/永久性(Durability)

• 一個(gè)事務(wù)一旦提交嘉抓，它對(duì)數(shù)據(jù)庫中數(shù)據(jù)的改變就應(yīng)該是永久性的索守。

事務(wù)隔離級(jí)別

事務(wù)不隔離可能導(dǎo)致的問題有：

• 臟讀: 臟讀就是指當(dāng)一個(gè)事務(wù)正在訪問數(shù)據(jù)，并且對(duì)數(shù)據(jù)進(jìn)行了修改抑片，而這種修改還沒有提交到數(shù)據(jù)庫中卵佛，這時(shí)，另外一個(gè)事務(wù)也訪問這個(gè)數(shù)據(jù)蓝丙，然后使用了這個(gè)數(shù)據(jù)级遭。
• 幻讀：幻讀:第一個(gè)事務(wù)對(duì)一個(gè)表中的數(shù)據(jù)進(jìn)行了修改，這種修改涉及到表中的全部數(shù)據(jù)行渺尘。同時(shí)挫鸽，第二個(gè)事務(wù)也修改這個(gè)表中的數(shù)據(jù)，這種修改是向表中插入一行新數(shù)據(jù)鸥跟。那么丢郊，以后就會(huì)發(fā)生操作第一個(gè)事務(wù)的用戶發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行，就好象發(fā)生了幻覺一樣医咨。
• 不可重復(fù)讀：是指在一個(gè)事務(wù)內(nèi)枫匾，多次讀同一數(shù)據(jù)。在這個(gè)事務(wù)還沒有結(jié)束時(shí)拟淮，另外一個(gè)事務(wù)也訪問該同一數(shù)據(jù)干茉。那么，在第一個(gè)事務(wù)中的兩次讀數(shù)據(jù)之間很泊，由于第二個(gè)事務(wù)的修改角虫，那么第一個(gè)事務(wù)兩次讀到的的數(shù)據(jù)可能是不一樣的。這樣就發(fā)生了在一個(gè)事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的委造，因此稱為是不可重復(fù)讀戳鹅。
• 可重復(fù)讀:可重復(fù)讀(REPEATABLE READS),由于提交讀隔離級(jí)別會(huì)產(chǎn)生不可重復(fù)讀的讀現(xiàn)象。所以昏兆，比提交讀更高一個(gè)級(jí)別的隔離級(jí)別就可以解決不可重復(fù)讀的問題枫虏。這種隔離級(jí)別就叫可重復(fù)讀

隔離級(jí)別：

• 未提交讀(Read Uncommitted)：允許臟讀，也就是可能讀取到其他會(huì)話中未提交事務(wù)修改的數(shù)據(jù)

• 提交讀(Read Committed)：只能讀取到已經(jīng)提交的數(shù)據(jù)。Oracle等多數(shù)數(shù)據(jù)庫默認(rèn)都是該級(jí)別 (不重復(fù)讀)

• 可重復(fù)讀(Repeated Read)：可重復(fù)讀隶债。在同一個(gè)事務(wù)內(nèi)的查詢都是事務(wù)開始時(shí)刻一致的腾它，InnoDB默認(rèn)級(jí)別。在SQL標(biāo)準(zhǔn)中燃异，該隔離級(jí)別消除了不可重復(fù)讀携狭，但是還存在幻象讀

• 串行讀(Serializable)：完全串行化的讀，每次讀都需要獲得表級(jí)共享鎖回俐，讀寫相互都會(huì)阻塞

  針對(duì)上面各種情況逛腿，數(shù)據(jù)庫在解決上面的問題時(shí)定義不同的級(jí)別，用戶可以根據(jù)實(shí)際需求在性能和錯(cuò)誤之間進(jìn)行平衡配置仅颇。不同的數(shù)據(jù)庫的默認(rèn)隔離級(jí)別是不一樣的单默。

mysql事務(wù)實(shí)現(xiàn)原理

事務(wù)實(shí)現(xiàn)有兩種方式：一種是通過鎖的方式來實(shí)現(xiàn)，另外一種是通過MVCC版本進(jìn)行控制

如果有鎖的方式來實(shí)現(xiàn)忘瓦，innodb的鎖的類型有：record,gap,Next-Key lock

鎖

Record lock

單條索引記錄上加鎖搁廓，record lock鎖住的永遠(yuǎn)是索引，而非記錄本身耕皮，即使該表上沒有任何索引境蜕，那么innodb會(huì)在后臺(tái)創(chuàng)建一個(gè)隱藏的聚集主鍵索引，那么鎖住的就是這個(gè)隱藏的聚集主鍵索引凌停。所以說當(dāng)一條sql沒有走任何索引時(shí)粱年，那么將會(huì)在每一條聚集索引后面加X鎖，這個(gè)類似于表鎖罚拟，但原理上和表鎖應(yīng)該是完全不同的台诗。

Gap lock

在索引記錄之間的間隙中加鎖，或者是在某一條索引記錄之前或者之后加鎖赐俗，并不包括該索引記錄本身拉队。gap lock的機(jī)制主要是解決可重復(fù)讀模式下的幻讀問題，關(guān)于幻讀的演示和gap鎖如何解決了幻讀阻逮。關(guān)于這一塊粱快，先給出幾個(gè)定義

• 快照讀：
  簡單的select操作，沒有l(wèi)ock in share mode或for update叔扼，快照讀不會(huì)加任何的鎖事哭，而且由于mysql的一致性非鎖定讀的機(jī)制存在，任何快照讀也不會(huì)被阻塞币励。但是如果事務(wù)的隔離級(jí)別是SERIALIZABLE的話，那么快照讀也會(huì)被加上共享的next-key鎖珊拼，本文不對(duì)SERIALIZABLE隔離級(jí)別做敘述食呻。

• 當(dāng)前讀：
  官方文檔的術(shù)語叫l(wèi)ocking read，也就是insert，update仅胞，delete,select..in share mode和select..for update,當(dāng)前讀會(huì)在所有掃描到的索引記錄上加鎖每辟，不管它后面的where條件到底有沒有命中對(duì)應(yīng)的行記錄。當(dāng)前讀可能會(huì)引起死鎖干旧。

• 意向鎖：
  innodb的意向鎖主要用戶多粒度的鎖并存的情況渠欺。比如事務(wù)A要在一個(gè)表上加S鎖，如果表中的一行已被事務(wù)B加了X鎖椎眯，那么該鎖的申請(qǐng)也應(yīng)被阻塞挠将。如果表中的數(shù)據(jù)很多，逐行檢查鎖標(biāo)志的開銷將很大编整，系統(tǒng)的性能將會(huì)受到影響舔稀。為了解決這個(gè)問題，可以在表級(jí)上引入新的鎖類型來表示其所屬行的加鎖情況掌测，這就引出了“意向鎖”的概念内贮。舉個(gè)例子，如果表中記錄1億汞斧，事務(wù)A把其中有幾條記錄上了行鎖了夜郁，這時(shí)事務(wù)B需要給這個(gè)表加表級(jí)鎖，如果沒有意向鎖的話粘勒，那就要去表中查找這一億條記錄是否上鎖了竞端。如果存在意向鎖，那么假如事務(wù)Ａ在更新一條記錄之前仲义，先加意向鎖婶熬，再加Ｘ鎖，事務(wù)B先檢查該表上是否存在意向鎖埃撵，存在的意向鎖是否與自己準(zhǔn)備加的鎖沖突赵颅，如果有沖突，則等待直到事務(wù)Ａ釋放暂刘，而無須逐條記錄去檢測(cè)饺谬。事務(wù)Ｂ更新表時(shí)，其實(shí)無須知道到底哪一行被鎖了谣拣，它只要知道反正有一行被鎖了就行了萨咳。
  說白了意向鎖的主要作用是處理行鎖和表鎖之間的矛盾，能夠顯示“某個(gè)事務(wù)正在某一行上持有了鎖悬垃，或者準(zhǔn)備去持有鎖”

• 不可重復(fù)讀：
  指的是在同一個(gè)事務(wù)中奕谭，連續(xù)幾次快照讀，讀取的記錄應(yīng)該是一樣的

• 幻讀：
  指的是在一個(gè)事務(wù)A中執(zhí)行了一個(gè)當(dāng)前讀操作贵涵，而另外一個(gè)事務(wù)B在事務(wù)A的影響區(qū)間內(nèi)insert了一條記錄列肢，這時(shí)事務(wù)A再執(zhí)行一個(gè)當(dāng)前讀操作時(shí)恰画，出現(xiàn)了幻行。這和不可重復(fù)讀的主要區(qū)別就在與事務(wù)A中一個(gè)是快照讀瓷马，一個(gè)當(dāng)前讀拴还；并且事務(wù)B中一個(gè)是任何的dml操作，一個(gè)只是insert欧聘。比如在A中select * from test where id<10 lock in share mode結(jié)果集為（1,2,3）片林，這時(shí)在B中對(duì)test表插入了一條記錄4，這時(shí)在A中重新查詢結(jié)果集就是(1,2,3,4）怀骤，和事務(wù)A在第一次查詢出來的結(jié)果集不一致费封，這里的4就是幻行。

MVCC版本控制

多版本控制: 指的是一種提高并發(fā)的技術(shù)晒喷。最早的數(shù)據(jù)庫系統(tǒng)孝偎，只有讀讀之間可以并發(fā)，讀寫凉敲，寫讀衣盾，寫寫都要阻塞。引入多版本之后爷抓，只有寫寫之間相互阻塞势决，其他三種操作都可以并行，這樣大幅度提高了InnoDB的并發(fā)度蓝撇。在內(nèi)部實(shí)現(xiàn)中果复，與Postgres在數(shù)據(jù)行上實(shí)現(xiàn)多版本不同，InnoDB是在undolog中實(shí)現(xiàn)的渤昌，通過undolog可以找回?cái)?shù)據(jù)的歷史版本虽抄。找回的數(shù)據(jù)歷史版本可以提供給用戶讀(按照隔離級(jí)別的定義，有些讀請(qǐng)求只能看到比較老的數(shù)據(jù)版本)独柑，也可以在回滾的時(shí)候覆蓋數(shù)據(jù)頁上的數(shù)據(jù)迈窟。在InnoDB內(nèi)部中，會(huì)記錄一個(gè)全局的活躍讀寫事務(wù)數(shù)組忌栅，其主要用來判斷事務(wù)的可見性车酣。

定義：

1.read view, 快照snapshot

淘寶數(shù)據(jù)庫內(nèi)核月報(bào)/2017/10/01/
此文雖然是以PostgreSQL進(jìn)行的說明, 但并不影響理解, 在"事務(wù)快照的實(shí)現(xiàn)"該部分有細(xì)節(jié)需要注意:
事務(wù)快照是用來存儲(chǔ)數(shù)據(jù)庫的事務(wù)運(yùn)行情況。一個(gè)事務(wù)快照的創(chuàng)建過程可以概括為：
查看當(dāng)前所有的未提交并活躍的事務(wù)索绪，存儲(chǔ)在數(shù)組中
選取未提交并活躍的事務(wù)中最小的XID湖员，記錄在快照的xmin中
選取所有已提交事務(wù)中最大的XID，加1后記錄在xmax中
注意: 上文中在PostgreSQL中snapshot的概念, 對(duì)應(yīng)MySQL中, 其實(shí)就是你在網(wǎng)上看到的read view,快照這些概念;
比如何登成就有關(guān)于Read view的介紹;
而 此文 卻仍是使用快照來介紹;

2.read view 主要是用來做可見性判斷的, 比較普遍的解釋便是"本事務(wù)不可見的當(dāng)前其他活躍事務(wù)", 但正是該解釋, 可能會(huì)造成一節(jié)理解上的誤區(qū), 所以此處提供兩個(gè)參考, 供給大家避開理解誤區(qū):

read view中的高水位low_limit_id可以參考 https://github.com/zhangyachen/zhangyachen.github.io/issues/68, https://www.zhihu.com/question/66320138
其實(shí)上面第1點(diǎn)中加粗部分也是相關(guān)高水位的介紹( 注意進(jìn)行了+1 )
3.另外, 對(duì)于read view快照的生成時(shí)機(jī), 也非常關(guān)鍵, 正是因?yàn)樯蓵r(shí)機(jī)的不同, 造成了RC,RR兩種隔離級(jí)別的不同可見性;

在innodb中(默認(rèn)repeatable read級(jí)別), 事務(wù)在begin/start transaction之后的第一條select讀操作后, 會(huì)創(chuàng)建一個(gè)快照(read view), 將當(dāng)前系統(tǒng)中活躍的其他事務(wù)記錄記錄起來;
在innodb中(默認(rèn)repeatable committed級(jí)別), 事務(wù)中每條select語句都會(huì)創(chuàng)建一個(gè)快照(read view);

參考
With REPEATABLE READ isolation level, the snapshot is based on the time when the first read operation is performed.
使用REPEATABLE READ隔離級(jí)別瑞驱，快照是基于執(zhí)行第一個(gè)讀操作的時(shí)間娘摔。
With READ COMMITTED isolation level, the snapshot is reset to the time of each consistent read operation.
使用READ COMMITTED隔離級(jí)別，快照被重置為每個(gè)一致的讀取操作的時(shí)間唤反。

4.undo-log

Undo log是InnoDB MVCC事務(wù)特性的重要組成部分凳寺。當(dāng)我們對(duì)記錄做了變更操作時(shí)就會(huì)產(chǎn)生undo記錄嫡丙，Undo記錄默認(rèn)被記錄到系統(tǒng)表空間(ibdata)中，但從5.6開始读第，也可以使用獨(dú)立的Undo 表空間。
Undo記錄中存儲(chǔ)的是老版本數(shù)據(jù)拥刻，當(dāng)一個(gè)舊的事務(wù)需要讀取數(shù)據(jù)時(shí)怜瞒，為了能讀取到老版本的數(shù)據(jù)，需要順著undo鏈找到滿足其可見性的記錄般哼。當(dāng)版本鏈很長時(shí)吴汪，通常可以認(rèn)為這是個(gè)比較耗時(shí)的操作（例如bug#69812）蒸眠。
大多數(shù)對(duì)數(shù)據(jù)的變更操作包括INSERT/DELETE/UPDATE漾橙，其中INSERT操作在事務(wù)提交前只對(duì)當(dāng)前事務(wù)可見，因此產(chǎn)生的Undo日志可以在事務(wù)提交后直接刪除（誰會(huì)對(duì)剛插入的數(shù)據(jù)有可見性需求呢＠憧āＫ恕），而對(duì)于UPDATE/DELETE則需要維護(hù)多版本信息蒋腮，在InnoDB里淘捡，UPDATE和DELETE操作產(chǎn)生的Undo日志被歸成一類，即update_undo
另外, 在回滾段中的undo logs分為: insert undo log 和 update undo log

insert undo log : 事務(wù)對(duì)insert新記錄時(shí)產(chǎn)生的undolog, 只在事務(wù)回滾時(shí)需要, 并且在事務(wù)提交后就可以立即丟棄池摧。
update undo log : 事務(wù)對(duì)記錄進(jìn)行delete和update操作時(shí)產(chǎn)生的undo log, 不僅在事務(wù)回滾時(shí)需要, 一致性讀也需要焦除，所以不能隨便刪除，只有當(dāng)數(shù)據(jù)庫所使用的快照中不涉及該日志記錄作彤，對(duì)應(yīng)的回滾日志才會(huì)被purge線程刪除膘魄。

5.InnoDB存儲(chǔ)引擎在數(shù)據(jù)庫每行數(shù)據(jù)的后面添加了三個(gè)字段

• 6字節(jié)的事務(wù)ID(DB_TRX_ID)字段: 用來標(biāo)識(shí)最近一次對(duì)本行記錄做修改(insert|update)的事務(wù)的標(biāo)識(shí)符, 即最后一次修改(insert|update)本行記錄的事務(wù)id。
  至于delete操作竭讳，在innodb看來也不過是一次update操作创葡，更新行中的一個(gè)特殊位將行表示為deleted, 并非真正刪除。
• 7字節(jié)的回滾指針(DB_ROLL_PTR)字段: 指寫入回滾段(rollback segment)的 undo log record (撤銷日志記錄記錄)代咸。
  如果一行記錄被更新, 則 undo log record 包含 '重建該行記錄被更新之前內(nèi)容' 所必須的信息蹈丸。
• 6字節(jié)的DB_ROW_ID字段: 包含一個(gè)隨著新行插入而單調(diào)遞增的行ID, 當(dāng)由innodb自動(dòng)產(chǎn)生聚集索引時(shí)，聚集索引會(huì)包括這個(gè)行ID的值呐芥，否則這個(gè)行ID不會(huì)出現(xiàn)在任何索引中逻杖。
  結(jié)合聚簇索引的相關(guān)知識(shí)點(diǎn), 我的理解是, 如果我們的表中沒有主鍵或合適的唯一索引, 也就是無法生成聚簇索引的時(shí)候, InnoDB會(huì)幫我們自動(dòng)生成聚集索引, 但聚簇索引會(huì)使用DB_ROW_ID的值來作為主鍵; 如果我們有自己的主鍵或者合適的唯一索引, 那么聚簇索引中也就不會(huì)包含 DB_ROW_ID 了 。
  關(guān)于聚簇索引, 《高性能MySQL》中的篇幅對(duì)我來說已經(jīng)夠用了, 稍后會(huì)整理一下以前的學(xué)習(xí)筆記, 然后更新上來思瘟。

6.可見性比較算法（這里每個(gè)比較算法后面的描述是建立在rr級(jí)別下荸百，rc級(jí)別也是使用該比較算法,此處未做描述）

設(shè)要讀取的行的最后提交事務(wù)id(即當(dāng)前數(shù)據(jù)行的穩(wěn)定事務(wù)id)為 trx_id_current
當(dāng)前新開事務(wù)id為 new_id
當(dāng)前新開事務(wù)創(chuàng)建的快照read view 中最早的事務(wù)id為up_limit_id, 最遲的事務(wù)id為low_limit_id(注意這個(gè)low_limit_id=未開啟的事務(wù)id=當(dāng)前最大事務(wù)id+1)

比較:

• 1.trx_id_current < up_limit_id, 這種情況比較好理解, 表示, 新事務(wù)在讀取該行記錄時(shí), 該行記錄的穩(wěn)定事務(wù)ID是小于, 系統(tǒng)當(dāng)前所有活躍的事務(wù), 所以當(dāng)前行穩(wěn)定數(shù)據(jù)對(duì)新事務(wù)可見, 跳到步驟5.
• 2.trx_id_current >= trx_id_last, 這種情況也比較好理解, 表示, 該行記錄的穩(wěn)定事務(wù)id是在本次新事務(wù)創(chuàng)建之后才開啟的, 但是卻在本次新事務(wù)執(zhí)行第二個(gè)select前就commit了，所以該行記錄的當(dāng)前值不可見, 跳到步驟4滨攻。
• 3.trx_id_current <= trx_id_current <= trx_id_last, 表示: 該行記錄所在事務(wù)在本次新事務(wù)創(chuàng)建的時(shí)候處于活動(dòng)狀態(tài)够话，從up_limit_id到low_limit_id進(jìn)行遍歷蓝翰，如果trx_id_current等于他們之中的某個(gè)事務(wù)id的話，那么不可見, 調(diào)到步驟4,否則表示可見女嘲。
• 4.從該行記錄的 DB_ROLL_PTR 指針?biāo)赶虻幕貪L段中取出最新的undo-log的版本號(hào), 將它賦值該 trx_id_current畜份，然后跳到步驟1重新開始判斷。
• 5.將該可見行的值返回欣尼。

參考

• https://segmentfault.com/a/1190000012650596
• https://www.cnblogs.com/zhoujinyi/p/3437475.html
• https://blog.csdn.net/cug_jiang126com/article/details/50596729