mysql教程總結數(shù)據(jù)庫事務與 MySQL 事務

推薦（免費）：mysql教程

事務特點：ACID

從業(yè)務角度出發(fā)，對數(shù)據(jù)庫的一組操作要求保持4個特征：

• Atomicity（原子性）：一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要么全部提交成功，要么全部失敗回滾，對于一個事務來說，不可能只執(zhí)行其中的一部分操作。
• Consistency（一致性）：數(shù)據(jù)庫總是從一個一致性狀態(tài)轉換到另一個一致狀態(tài)。下面的銀行列子會說到。
• Isolation（隔離性）：通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。注意這里的“通常來說”，后面的事務隔離級級別會說到。
• Durability（持久性）：一旦事務提交，則其所做的修改就會永久保存到數(shù)據(jù)庫中。此時即使系統(tǒng)崩潰，修改的數(shù)據(jù)也不會丟失。（持久性的安全性與刷新日志級別也存在一定關系，不同的級別對應不同的數(shù)據(jù)安全級別。）

為了更好地理解ACID，以銀行賬戶轉賬為例：

START TRANSACTION;SELECT balance FROM checking WHERE customer_id = 10233276;UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 10233276;UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 10233276;COMMIT;

• 原子性：要么完全提交（10233276的checking余額減少200，savings 的余額增加200），要么完全回滾（兩個表的余額都不發(fā)生變化）
• 一致性：這個例子的一致性體現(xiàn)在 200元不會因為數(shù)據(jù)庫系統(tǒng)運行到第3行之后，第4行之前時崩潰而不翼而飛，因為事務還沒有提交。
• 隔離性：允許在一個事務中的操作語句會與其他事務的語句隔離開，比如事務A運行到第3行之后，第4行之前，此時事務B去查詢checking余額時，它仍然能夠看到在事務A中被減去的200元（賬戶錢不變），因為事務A和B是彼此隔離的。在事務A提交之前，事務B觀察不到數(shù)據(jù)的改變。
• 持久性：這個很好理解。
• 事務的隔離性是通過鎖、MVCC等實現(xiàn) （MySQL鎖總結）
• 事務的原子性、一致性和持久性則是通過事務日志實現(xiàn)（見下）

事務的隔離級別

并發(fā)事務帶來的問題

• 更新丟失（Lost Update）：當兩個或多個事務選擇同一行，然后基于最初選定的值更新該行時，由于每個事務都不知道其他事務的存在，就會發(fā)生丟失更新問題 －－最后的更新覆蓋了由其他事務所做的更新。例如，兩個編輯人員制作了同一 文檔的電子副本。每個編輯人員獨立地更改其副本，然后保存更改后的副本，這樣就覆蓋了原始文檔。 最后保存其更改副本的編輯人員覆蓋另一個編輯人員所做的更改。如果在一個編輯人員完成并提交事務之前，另一個編輯人員不能訪問同 一文件，則可避免此問題。
• 臟讀（Dirty Reads）：一個事務正在對一條記錄做修改，在這個事務完成并提交前， 這條記錄的數(shù)據(jù)就處于不一致狀態(tài)； 這時， 另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“臟”數(shù)據(jù)，并據(jù)此做進一步的處理，就會產(chǎn)生未提交的數(shù)據(jù)依賴關系。這種現(xiàn)象被形象地叫做”臟讀”。
• 不可重復讀（Non-Repeatable Reads）：一個事務在讀取某些數(shù)據(jù)后的某個時間，再次讀取以前讀過的數(shù)據(jù)，卻發(fā)現(xiàn)其讀出的數(shù)據(jù)已經(jīng)發(fā)生了改變、或某些記錄已經(jīng)被刪除了！這種現(xiàn)象就叫做“不可重復讀” 。
• 幻讀 （Phantom Reads）： 一個事務按相同的查詢條件重新讀取以前檢索過的數(shù)據(jù)，卻發(fā)現(xiàn)其他事務插入了滿足其查詢條件的新數(shù)據(jù)，這種現(xiàn)象就稱為“幻讀” 。

幻讀和不可重復讀的區(qū)別：

• 不可重復讀的重點是修改：在同一事務中，同樣的條件，第一次讀的數(shù)據(jù)和第二次讀的數(shù)據(jù)不一樣。（因為中間有其他事務提交了修改）
• 幻讀的重點在于新增或者刪除：在同一事務中，同樣的條件,，第一次和第二次讀出來的記錄數(shù)不一樣。（因為中間有其他事務提交了插入/刪除）

并發(fā)事務處理帶來的問題的解決辦法：

• “更新丟失”通常是應該完全避免的。但防止更新丟失，并不能單靠數(shù)據(jù)庫事務控制器來解決，需要應用程序對要更新的數(shù)據(jù)加必要的鎖來解決，因此，防止更新丟失應該是應用的責任。

• “臟讀” 、 “不可重復讀”和“幻讀” ，其實都是數(shù)據(jù)庫讀一致性問題，必須由數(shù)據(jù)庫提供一定的事務隔離機制來解決：

• 一種是加鎖：在讀取數(shù)據(jù)前，對其加鎖，阻止其他事務對數(shù)據(jù)進行修改。

• 另一種是數(shù)據(jù)多版本并發(fā)控制（MultiVersion Concurrency Control，簡稱 MVCC 或 MCC），也稱為多版本數(shù)據(jù)庫：不用加任何鎖， 通過一定機制生成一個數(shù)據(jù)請求時間點的一致性數(shù)據(jù)快照 （Snapshot)， 并用這個快照來提供一定級別 （語句級或事務級） 的一致性讀取。從用戶的角度來看，好象是數(shù)據(jù)庫可以提供同一數(shù)據(jù)的多個版本。

SQL標準定義了4類隔離級別，每一種級別都規(guī)定了一個事務中所做的修改，哪些在事務內和事務間是可見的，哪些是不可見的。低級別的隔離級一般支持更高的并發(fā)處理，并擁有更低的系統(tǒng)開銷。

第1級別：Read Uncommitted(讀取未提交內容)

• 所有事務都可以看到其他未提交事務的執(zhí)行結果
• 本隔離級別很少用于實際應用，因為它的性能也不比其他級別好多少
• 該級別引發(fā)的問題是——臟讀(Dirty Read)：讀取到了未提交的數(shù)據(jù)

第2級別：Read Committed(讀取提交內容)

• 這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認隔離級別（但不是MySQL默認的）

• 它滿足了隔離的簡單定義：一個事務只能看見已經(jīng)提交事務所做的改變

• 這種隔離級別出現(xiàn)的問題是——不可重復讀(Nonrepeatable Read)：不可重復讀意味著我們在同一個事務中執(zhí)行完全相同的select語句時可能看到不一樣的結果。導致這種情況的原因可能有：

• 有一個交叉的事務有新的commit，導致了數(shù)據(jù)的改變;

• 一個數(shù)據(jù)庫被多個實例操作時,同一事務的其他實例在該實例處理其間可能會有新的commit

第3級別：Repeatable Read(可重讀)

• 這是MySQL的默認事務隔離級別
• 它確保同一事務的多個實例在并發(fā)讀取數(shù)據(jù)時，會看到同樣的數(shù)據(jù)行
• 此級別可能出現(xiàn)的問題——幻讀(Phantom Read)：當用戶讀取某一范圍的數(shù)據(jù)行時，另一個事務又在該范圍內插入了新行，當用戶再讀取該范圍的數(shù)據(jù)行時，會發(fā)現(xiàn)有新的“幻影” 行
• InnoDB和Falcon存儲引擎通過多版本并發(fā)控制(MVCC，Multiversion Concurrency Control)機制解決幻讀問題；InnoDB還通過間隙鎖解決幻讀問題

多版本并發(fā)控制 :

Mysql的大多數(shù)事務型存儲引擎實現(xiàn)都不是簡單的行級鎖。基于提升并發(fā)性考慮，一般都同時實現(xiàn)了多版本并發(fā)控制（MVCC），包括Oracle、PostgreSQL。不過實現(xiàn)各不相同。

MVCC的實現(xiàn)是通過保存數(shù)據(jù)在某一個時間點快照來實現(xiàn)的。也就是說不管實現(xiàn)時間多長，每個事物看到的數(shù)據(jù)都是一致的。

分為樂觀（optimistic）并發(fā)控制和悲觀（pressimistic）并發(fā)控制。

MVCC是如何工作的：

InnoDB的MVCC是通過在每行記錄后面保存兩個隱藏的列來實現(xiàn)。這兩個列一個保存了行的創(chuàng)建時間，一個保存行的過期時間（刪除時間）。當然存儲的并不是真實的時間而是系統(tǒng)版本號（system version number）。每開始一個新的事務，系統(tǒng)版本號都會自動新增。事務開始時刻的系統(tǒng)版本號會作為事務的版本號，用來查詢到每行記錄的版本號進行比較。

REPEATABLE READ（可重讀）隔離級別下MVCC如何工作：

• SELECT

InnoDB會根據(jù)以下條件檢查每一行記錄：

1. InnoDB只查找版本早于當前事務版本的數(shù)據(jù)行，這樣可以確保事務讀取的行要么是在開始事務之前已經(jīng)存在要么是事務自身插入或者修改過的
2. 行的刪除版本號要么未定義，要么大于當前事務版本號，這樣可以確保事務讀取到的行在事務開始之前未被刪除

只有符合上述兩個條件的才會被查詢出來

• INSERT

InnoDB為新插入的每一行保存當前系統(tǒng)版本號作為行版本號

• DELETE

InnoDB為刪除的每一行保存當前系統(tǒng)版本號作為行刪除標識

• UPDATE

InnoDB為插入的一行新紀錄保存當前系統(tǒng)版本號作為行版本號，同時保存當前系統(tǒng)版本號到原來的行作為刪除標識

保存這兩個版本號，使大多數(shù)操作都不用加鎖。使數(shù)據(jù)操作簡單，性能很好，并且能保證只會讀取到復合要求的行。不足之處是每行記錄都需要額外的存儲空間，需要做