Mysql併發控制

最近在看Mysql的併發控制，事務處理等知識，作些整理。

併發控制目的是當多個鏈接對數據庫進行修改時保證數據的一致性。如今mysql的InnoDB在update，delete時使用行級鎖，對於select會結合MVCC保證一致性。

一、 併發控制
MySQL提供兩個級別的併發控制：服務器級(the server level)和存儲引擎級(the storage engine level)。加鎖是實現併發控制的基本方法，MySQL中鎖的粒度：
(1)    表級鎖：MySQL獨立於存儲引擎提供表鎖，例如，對於ALTER TABLE語句，服務器提供表鎖(table-level lock)。
(2)    行級鎖：InnoDB和Falcon存儲引擎提供行級鎖，此外，BDB支持頁級鎖。InnoDB的併發控制機制，下節詳細討論。
另外，值得一提的是，MySQL的一些存儲引擎（如InnoDB、BDB）除了使用封鎖機制外，還同時結合MVCC機制，即多版本兩階段封鎖協議MVCC(Multiversion two-phrase locking protocal)，來實現事務的併發控制，從而使得只讀事務不用等待鎖，提升了事務的併發性。

數據庫的事務處理的原則是保證ACID的正確性。

二、事務處理

2.1 事務的ACID特性
事務是由一組SQL語句組成的邏輯處理單元，事務具備如下4個屬性：
(1)原子性（Atomicity）：事務是一個原子操做單元，其對數據的修改，要麼全都執行，要麼全都不執行。
(2)一致性（Consistent）：在事務開始和完成時，數據都必須保持一致狀態。這意味着全部相關的數據規則都必須應用於事務的修改，以保持數據的完整性；事務結束時，全部的內部數據結構（如B樹索引或雙向鏈表）也都必須是正確的。
(3)隔離性（Isolation）：數據庫系統提供必定的隔離機制，保證事務在不受外部併發操做影響的「獨立」環境執行。這意味着事務處理過程當中的中間狀態對外部是不可見的，反之亦然。
(4)持久性（Durable）：事務完成以後，它對於數據的修改是永久性的，即便出現系統故障也可以保持。

2.二、事務處理帶來的相關問題
因爲事務的併發執行，帶來如下一些著名的問題：
(1)更新丟失（Lost Update）：當兩個或多個事務選擇同一行，而後基於最初選定的值更新該行時，因爲每一個事務都不知道其餘事務的存在，就會發生丟失更新問題－－最後的更新覆蓋了由其餘事務所作的更新。
(2)髒讀（Dirty Reads）：一個事務正在對一條記錄作修改，在這個事務完成並提交前，這條記錄的數據就處於不一致狀態；這時，另外一個事務也來讀取同一條記錄，若是不加控制，第二個事務讀取了這些「髒」數據，並據此作進一步的處理，就會產生未提交的數據依賴關係。這種現象被形象地叫作"髒讀"。
(3)不可重複讀（Non-Repeatable Reads）：一個事務在讀取某些數據後的某個時間，再次讀取之前讀過的數據，卻發現其讀出的數據已經發生了改變、或某些記錄已經被刪除了！這種現象就叫作「不可重複讀」。
(4)幻讀（Phantom Reads）：一個事務按相同的查詢條件從新讀取之前檢索過的數據，卻發現其餘事務插入了知足其查詢條件的新數據，這種現象就稱爲「幻讀」。

3. Mysql隔離級別：

READ UNCOMMITTED ：事務能夠看到其餘事務沒有被提交的數據（髒數據）
READ COMMITTED ：事務能夠看到其餘事務已經提交的數據
REPEATABLE READ ：事務中兩次查詢的結果相同。（Innodb默認級別）
SERIALIZABLE ：全部事務順序執行，對全部read操做加鎖。保證一致性。

4. 注意點：

（1）InnoDb經過MVCC防止了幻讀(Phantom Read)，即兩次select之間有另外一個事務插入了數據而且commit，兩次select也是保證一致性的。可是若是事務B的insert/update/delete語句執行時間和commit時間在本事務A的第一個select以前，則事務A的第一個select是能夠讀到事務B的更新數據的。

（2）若是一個事務A，先進行了update/insert/delete操做，在進行第一次select操做，那麼select是能夠讀到更新的時間，這樣形成的結果是select可能讀到根本不存在的數據（http://dev.mysql.com/doc/refman/5.1/en/innodb-consistent-read.html）

（3）若是一個事務A進行了select操做，那麼在這個select開始後的其餘事務B進行了對數據的更新操做(update/insert/delete)，事務A的select將不會看到事務B操做的結果。事務Aselect在遍歷過程當中會遇到兩種狀況，一種是當前遍歷的行時正在被更新(update/insert/delete)，那麼這一行會被加上write lock鎖。另外一種是，當前遍歷的行沒有被加鎖。

對於第一種請，Innodb處理方式是select過程當中出逐行遍歷數據，若是某一行被write lock了，那麼會去undo段裏面找這一行的前一個snapshot數據，這個snapshot數據是由write操做引發的，每次write操做都將保存當前事務時刻的原始數據，用於write失敗進行回滾，因此是放在undo數據段裏面。

對於第二種狀況：能夠經過事務的編號進行過濾，innodb的每一個事務都有個事務編號保存在每一行數據的隱藏字段裏，若是當前事務編號比數據記錄裏面的隱藏字段的事務編號小，那麼表示當前數據是被當前事務後面的事務更新的，那麼不取當前數據，而是去undo段裏取snapshot數據。

（Mysql文檔的原文是：Suppose that you are running in the default REPEATABLE READ isolation level. When you issue a consistent read (that is, an ordinary SELECT statement), InnoDB gives your transaction a timepoint according to which your query sees the database. If another transaction deletes a row and commits after your timepoint was assigned, you do not see the row as having been deleted. Inserts and updates are treated similarly.）