事務
事務保證一組數據庫操作要么成功要么失敗
當數據庫中有多個事務同時進行時依啰，可能會出現臟讀（dirty read），不可重復讀（non-repeatable read）案训，幻讀（phantom read）問題买置，數據庫的事務隔離級別能解決這些問題。
事務隔離級別
SQL 標準的事務隔離級別包括
- 讀未提交（read uncommitted）：一個事務還沒有提交强霎，他所做的變更能被其他事務看到
- 讀提交（read committed）：一個事務提交了之后忿项，他所做的變更才能被其他事務看到
- 可重復讀（repeatable read）：一個事務在執(zhí)行過程中，他所看到的數據總是和在該事務啟動時看到的數據視圖是一致的。同時轩触，該事務未提交的變更對其他事務也是不可見的
- 串行讀（serializable read）：對于同一行數據寞酿，讀會加上讀鎖，寫會加上寫鎖脱柱，當出現讀寫鎖沖突的時候伐弹，后一個事務必須等待前一個事務執(zhí)行完成才能繼續(xù)執(zhí)行
InnoDB 存儲引擎的事務隔離級別的實現
數據庫會創(chuàng)建視圖，訪問的時候以視圖的邏輯結果為準榨为。
對于 讀未提交 惨好，直接返回記錄的最新值，不存在視圖的概念柠逞；
對于 讀提交 昧狮，在每個 SQL 語句開始執(zhí)行的時候會創(chuàng)建一個視圖；
對于 可重復讀 板壮，在每個事務啟動時候會創(chuàng)建一個視圖逗鸣，整個事務過程中都使用該視圖；
對于 串行讀绰精，是直接用鎖來避免串行訪問的撒璧；
那么，這個視圖（即快照）是怎樣創(chuàng)建與實現的呢笨使？
對于 可重復讀 隔離級別卿樱，事務在啟動的時候會創(chuàng)建快照，這個快照是基于整個庫的硫椰，這個快照不是拷貝數據庫中的所有數據生成的繁调。InnoDB 中每一個事務都有一個唯一的事務ID（transaction id），它是事務開始的時候向 InnoDB 的事務系統申請的靶草，并且是嚴格自增的（TODO：事務id的值范圍蹄胰，超過了會發(fā)生什么），而且數據庫的每行數據都有多個版本奕翔，每次事務更新數據的時候裕寨，都會生成一個新的版本，并且把事務的 transaction id 賦值給這個數據版本的事務 id派继，記為 row trx_id宾袜。同時，舊的數據版本會保留驾窟，并且在新的數據版本中庆猫，通過 undo log 能夠得到舊版本的數據，下面是一個簡單的圖示：
????這一行此時有四個 version绅络，v4 是最新的阅悍，它被 transaction id 為 999 的事務更新好渠，因此這個version的 row trx_id 是 999。
????當然节视，v1拳锚，v2，v3 并不是物理上真正存在的寻行，而是需要的時候通過 v4 和 undo log 計算出來的霍掺。
????當一個事務啟動的瞬間，InnoDB會為該事務構造一個數組拌蜘，用來保存當前所有活躍的事務（即還沒有提交的事務）的 transaction id 杆烁，數組中事務 id 最小的被記為低水位，當前系統已經創(chuàng)建過的事務id的最大值加1被記為高水位简卧，這個視圖數組和高水位就組成了當前事務的一致性視圖兔魂，數據版本的可見性就是根據當前事務的id和這個一致性視圖的對比結果得到的。
????所以在事務啟動的瞬間举娩，一致性視圖把當前系統所有的row trx_id 分成了以下幾種情況:
- 若落在黃色部分析校，表示這個版本是已提交的事務或者是當前事務自己生成的，這個數據是可見的
- 若落在紫色部分铜涉，表示這個版本是由將來啟動的事務生成的智玻，是肯定不可見的
- 若落在綠色部分，那包含兩種情況
a) 若row trx_id 在數組中芙代，表示這個版本是由未提交的事務生成的吊奢，不可見
b)若row trx_id 不在數組中，表示這個版本是由已經提交的事務生成的纹烹，可見
????因此页滚，對于圖一來說，假設一個事務的低水位是 777铺呵，那么訪問的那一行數據的時候逻谦，就會通過v4和undo log計算出v2版本時的值，所以在它看來陪蜻，這一行的值是 13
????接下來，我們舉一個栗子來實踐下：
- 建表：
create TABLE trans_1 (id int(4) not null PRIMARY KEY,k int(4));
insert into trans_1 values(1,1);
- 事務時序：
????????????????????????????????????????????????????????????表一
| 事務A | 事務B | 事務C |
|---|---|---|
| start transaction with consistent snapshot | ||
| start transaction with consistent snapshot | ||
| update trans_1 set k = k + 1 where id = 1; | ||
| update trans_1 set k = k + 1 where id = 1;select * FROM trans_1 where id = 1; | ||
| select * FROM trans_1 where id = 1;commit贱鼻； | ||
| commit |
我們不妨假設：
- 事務A開始之前宴卖，系統中只有一個活躍的事務，id為 66邻悬；
- 事務A症昏，事務B，事務C 的事務ID分別是 67,68,69父丰；
- 事務A開始之前肝谭，（1,1）這一行數據的數據的row trx_id 為 50掘宪；
這樣，事務A是視圖數組為[66,67]攘烛，高水位的值是68魏滚，事務B的視圖數組為[66,67,68]，高水位的值是69坟漱，事務C的視圖數組為[66,67,68,69]鼠次，高水位的值是70。
事務C 的更新使得id=1這一行的最新版本是 69 了芋齿，50 已經成為歷史版本腥寇，事務B 的更新使得 id=1 這一行的最新版本是 68 , 69 這個成為了歷史版本。在事務A進行select的時候觅捆，select 的邏輯是：
a)：id=1 這一行的最新版本 68赦役，位于高水位，不可見栅炒。
b)：通過undo log找到上一個版本掂摔，即 69 這個版本，比高水位大职辅，不可見
c)：再通過 undo log 找到上一個版本棒呛，即 50 這個版本，比低水位小域携，可見
所以 select 出來的就是 50 這個版本時候的值簇秒，即 k=1
說了這么多，數據可見性的整體感知就是：
- 版本未提交秀鞭，不可見
- 版本在事務啟動（視圖數組創(chuàng)建）之后提交趋观，不可見
- 版本在事務啟動之前提交，可見
在事務B 執(zhí)行 update 之后锋边，select出的 k 的值是3皱坛，會不會覺得奇怪呢？
事務B 在 update 之前豆巨，select 出 id=1 的 k 值是 1剩辟，即事務C 的 update 對事務B 是不可見的，事務B 的 update 應該是在 k=1 的基礎上進行的往扔。但為什么 select 出的值是 3 呢贩猎？這設計到一個當前讀的概念，當更新數據的時候萍膛，都是先讀后寫吭服，而這個讀，只能讀取當前的值蝗罗，稱為”當前讀“艇棕。所以事務B update 之前 k 的值是 2 （單獨去執(zhí)行 select 的話 k = 1）蝌戒，update 的時候是以 k =2 為基礎的，然后進行 select 的時候沼琉，發(fā)現數據的最新版本是 68北苟，而自己的版本號也是 68，判斷出是自己的更新刺桃，可以直接使用粹淋，所以 select 出的值就是 3
除了update語句外，如果select語句加上鎖也是可以當前讀的
如果 事務C update之后沒有立即提交瑟慈，那么情況會是怎樣的呢桃移？
????????????????????????????????????????????????????????????表二
| 事務A | 事務B | 事務C ~ |
|---|---|---|
| start transaction with consistent snapshot; | ||
| start transaction with consistent snapshot ; | ||
| start transaction with consistent snapshot;update trans_1 set k = k + 1 where id = 1; | ||
| update trans_1 set k = k + 1 where id = 1; select * FROM trans_1 where id = 1; | ||
| select * FROM trans_1 where id = 1; commit; | commit; | |
| commit; |
由于事務C update之后沒有提交，69 這個版本的寫鎖還沒有釋放葛碧，當事務B 去update的時候借杰，由于要當前讀，必須讀取最新的版本进泼，且要加鎖蔗衡，因此事務B就被阻塞了，直到事務C 提交之后乳绕，才能繼續(xù)當前讀
在 讀提交 級別下绞惦，由于是每一個語句對應一個視圖，
對于表一洋措，事務B select的結果是 3济蝉，事務A select的結果是 2
ps:如果你的答案不是這個，你可能需要再看一遍文章
