1. 數據庫事務ACID特性
數據庫事務的4個特性：
原子性(Atomic): 事務中的多個操作，不可分割，要麼都成功，要麼都失敗； All or Nothing.
一致性(Consistency): 事務操作之後, 數據庫所處的狀態和業務規則是一致的; 比如a,b賬戶相互轉賬之後，總金額不變；
隔離性(Isolation): 多個事務之間就像是串行執行一樣，不相互影響;
持久性(Durability): 事務提交後被持久化到永久存儲.
2. 隔離性
其中 隔離性 分為了四種：
READ UNCOMMITTED：可以讀取未提交的數據，未提交的數據稱為髒數據，所以又稱髒讀。此時：幻讀，不可重復讀和髒讀均允許；
READ COMMITTED：只能讀取已經提交的數據；此時：允許幻讀和不可重復讀，但不允許髒讀，所以RC隔離級別要求解決髒讀；
REPEATABLE READ：同一個事務中多次執行同一個select,讀取到的數據沒有發生改變；此時：允許幻讀，但不允許不可重復讀和髒讀，所以RR隔離級別要求解決不可重復讀；
SERIALIZABLE: 幻讀，不可重復讀和髒讀都不允許，所以serializable要求解決幻讀；
3. 幾個概念
髒讀：可以讀取未提交的數據。RC 要求解決髒讀；
不可重復讀：同一個事務中多次執行同一個select, 讀取到的數據發生了改變(被其它事務update並且提交)；
可重復讀：同一個事務中多次執行同一個select, 讀取到的數據沒有發生改變(一般使用MVCC實現)；RR各級級別要求達到可重復讀的標准；
幻讀：同一個事務中多次執行同一個select, 讀取到的數據行發生改變。也就是行數減少或者增加了(被其它事務delete/insert並且提交)。SERIALIZABLE要求解決幻讀問題；
這裡一定要區分 不可重復讀 和 幻讀：
不可重復讀的重點是修改:
同樣的條件的select, 你讀取過的數據, 再次讀取出來發現值不一樣了
幻讀的重點在於新增或者刪除:
同樣的條件的select, 第1次和第2次讀出來的記錄數不一樣
從結果上來看, 兩者都是為多次讀取的結果不一致。但如果你從實現的角度來看, 它們的區別就比較大：
對於前者, 在RC下只需要鎖住滿足條件的記錄，就可以避免被其它事務修改，也就是 select for update, select in share mode; RR隔離下使用MVCC實現可重復讀；
對於後者, 要鎖住滿足條件的記錄及所有這些記錄之間的gap，也就是需要 gap lock。
而ANSI SQL標准沒有從隔離程度進行定義，而是定義了事務的隔離級別，同時定義了不同事務隔離級別解決的三大並發問題：
Isolation Level
Dirty Read
Unrepeatable Read
Phantom Read
Read UNCOMMITTED
YES
YES
YES
READ COMMITTED
NO
YES
YES
READ REPEATABLE
NO
NO
YES
SERIALIZABLE
NO
NO
NO
參見：你真的明白事務的隔離性嗎？ (姜承堯)
4. 數據庫的默認隔離級別
除了MySQL默認采用RR隔離級別之外，其它幾大數據庫都是采用RC隔離級別。
但是他們的實現也是極其不一樣的。Oracle僅僅實現了RC 和 SERIALIZABLE隔離級別。默認采用RC隔離級別，解決了髒讀。但是允許不可重復讀和幻讀。其SERIALIZABLE則解決了髒讀、不可重復讀、幻讀。
MySQL的實現：MySQL默認采用RR隔離級別，SQL標准是要求RR解決不可重復讀的問題，但是因為MySQL采用了gap lock，所以實際上MySQL的RR隔離級別也解決了幻讀的問題。那麼MySQL的SERIALIZABLE是怎麼回事呢？其實MySQL的SERIALIZABLE采用了經典的實現方式，對讀和寫都加鎖。
5. MySQL 中RC和RR隔離級別的區別
MySQL數據庫中默認隔離級別為RR，但是實際情況是使用RC 和 RR隔離級別的都不少。好像淘寶、網易都是使用的 RC 隔離級別。那麼在MySQL中 RC 和 RR有什麼區別呢？我們該如何選擇呢？為什麼MySQL將RR作為默認的隔離級別呢？
5.1 RC 與 RR 在鎖方面的區別
1> 顯然 RR 支持 gap lock(next-key lock)，而RC則沒有gap lock。因為MySQL的RR需要gap lock來解決幻讀問題。而RC隔離級別則是允許存在不可重復讀和幻讀的。所以RC的並發一般要好於RR；
2> RC 隔離級別，通過 where 條件過濾之後，不符合條件的記錄上的行鎖，會釋放掉(雖然這裡破壞了“兩階段加鎖原則”)；但是RR隔離級別，即使不符合where條件的記錄，也不會是否行鎖和gap lock；所以從鎖方面來看，RC的並發應該要好於RR；
5.2 RC 與 RR 在復制方面的區別
1> RC 隔離級別不支持 statement 格式的bin log，因為該格式的復制，會導致主從數據的不一致；只能使用 mixed 或者 row 格式的bin log; 這也是為什麼MySQL默認使用RR隔離級別的原因。復制時，我們最好使用：binlog_format=row
具體參見：
http://blog.itpub.net/29254281/viewspace-1081678/
http://www.cnblogs.com/vinchen/archive/2012/11/19/2777919.html
2> MySQL5.6 的早期版本，RC隔離級別是可以設置成使用statement格式的bin log，後期版本則會直接報錯；
5.3 RC 與 RR 在一致性讀方面的區別
簡單而且，RC隔離級別時，事務中的每一條select語句會讀取到他自己執行時已經提交了的記錄，也就是每一條select都有自己的一致性讀ReadView; 而RR隔離級別時，事務中的一致性讀的ReadView是以第一條select語句的運行時，作為本事務的一致性讀snapshot的建立時間點的。只能讀取該時間點之前已經提交的數據。
具體可以參加：MySQL 一致性讀 深入研究
5.4 RC 支持半一致性讀，RR不支持
RC隔離級別下的update語句，使用的是半一致性讀(semi consistent)；而RR隔離級別的update語句使用的是當前讀；當前讀會發生鎖的阻塞。
1> 半一致性讀：
A type of read operation used for UPDATE statements, that is a combination of read committed and consistent read. When an UPDATE statement examines a row that is already locked, InnoDB returns the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again, and this time InnoDB either locks it or waits for a lock on it. This type of read operation can only happen when the transaction has the read committed isolation level, or when the innodb_locks_unsafe_for_binlog option is enabled.
簡單來說，semi-consistent read是read committed與consistent read兩者的結合。一個update語句，如果讀到一行已經加鎖的記錄，此時InnoDB返回記錄最近提交的版本，由MySQL上層判斷此版本是否滿足 update的where條件。若滿足(需要更新)，則MySQL會重新發起一次讀操作，此時會讀取行的最新版本(並加鎖)。semi-consistent read只會發生在read committed隔離級別下，或者是參數innodb_locks_unsafe_for_binlog被設置為true(該參數即將被廢棄)。
對比RR隔離級別，update語句會使用當前讀，如果一行被鎖定了，那麼此時會被阻塞，發生鎖等待。而不會讀取最新的提交版本，然後來判斷是否符合where條件。
半一致性讀的優點：
減少了update語句時行鎖的沖突；對於不滿足update更新條件的記錄，可以提前放鎖，減少並發沖突的概率。
具體可以參見：http://hedengcheng.com/?p=220
Oracle中的update好像有“重啟動”的概念。
