That way I want to stay

前幾天同事講了Transaction isolation level，并且大家一起在SQLServer，Oracle跟MySQL數據庫上實驗了一下，發(fā)覺這些知識還是挺重要的。
假如有兩個事務并發(fā)，順序如下
Transaction A            Transaction B
begin    begin
query1 from table A   
.......                  modify1 to table A(insert/update/delete)
   commit
query2 from table A
commit

那么在事務A中，query1跟query2查詢出來的結果是否一樣呢？這就跟事務隔離級別有關了。
SQL的標準定義里面，一共有四種級別：
read uncommited讀取未提交的數據　就是其他事務求提交的數據，都可以讀取出來
read commited讀取已提交的數據　query2會跟query1讀取的數據不一樣
repeatable read可重復讀取，即query1跟query2讀取的數據是一樣的
serializable　序列化，

 SQL 標準用三個必須在并行的事務之間避免的現象定義了四個級別的事務隔離。 這些不希望發(fā)生的現象是：
臟讀（dirty reads）
    一個事務讀取了另一個未提交的并行事務寫的數據。
不可重復讀（non-repeatable reads）
    一個事務重新讀取前面讀取過的數據， 發(fā)現該數據已經被另一個已提交的事務修改過。
幻讀（phantom read）
    一個事務重新執(zhí)行一個查詢，返回一套符合查詢條件的行， 發(fā)現這些行因為其他最近提交的事務而發(fā)生了改變。
 隔離級別   　　　　　 臟讀（Dirty Read）  不可重復讀（NonRepeatable Read）  幻讀（Phantom Read）
讀未提交（Read uncommitted）  　可能      可能                           可能
讀已提交（Read committed）  　  不可能　          可能                        可能
可重復讀（Repeatable read）    不可能             不可能                   　可能
可串行化（Serializable ）      不可能              不可能                  不可能

SQLServer
我們首先在SQLServer上做了實驗，SQLServer一共支持四種隔離級別，read uncommited跟read commited我們沒有實驗，我們直接先實驗
repeatable read，如果事務A定義了如下級別，那么當事務B執(zhí)行到modify1這條語句時，如果modify1是update的話，就被鎖起來，一直等
到事務A提交完以后，鎖才會被釋放，而如果是insert的話，剛可以順利進行下去，然后在事務A中，query2查到的數據，是已經被事務B
修改過的數據，如果將級別定義在serializable的話，則在modify1語句中，update,insert或者delete都會被鎖掉。
也就是說，SQLServer對這些級別的支持，是通過鎖來做到的，雖然可以保證事務正常進行，但是并行的性能卻很差。
Oracle
oracle只支持兩個級別，read commited跟serializable，結果這里就不用詳細說明，實驗的結果是，oracle的serializable是通過版本
控制來完成的，而不是通過鎖機制，這就保證了并行的性能。Oracle的默認級別是read commited
MySQL
MySQLServer也支持四個級別，而且MySQL也是通過版本控制而非鎖機制來完成的。