并發事務下各資料庫外部表現實測之六（總結篇）

根據并發事務的實作方式和外部表現，可以歸納出下面幾種事務處理模式（近似的）。

1）讀未送出

讀不加鎖，寫加排他鎖。寫鎖在事務結束時釋放。

讀寫不沖突，但可能出現髒讀。

2）讀已送出(基于鎖)

讀加共享鎖，寫加排他鎖。讀鎖在讀SQL執行後立即釋放，寫鎖在事務結束時釋放。

讀寫沖突，不會出現髒讀，但可能出現不可重複讀。

3）可重複讀(基于鎖)

讀加共享鎖，寫加排他鎖。讀鎖和寫鎖都在事務結束時釋放。

讀寫沖突。不會出現不可重複讀，但不能避免幻讀。

4）可串行化(基于鎖)

讀寫沖突。通過提高鎖的粒度等方式，避免幻讀。

5）讀已送出(基于MVCC)

讀時通過MVCC擷取查詢當時的快照，進而避免了對讀加鎖。

讀寫不沖突。

6）SNAPSHOT ISOLATION(SI)

讀時通過MVCC擷取事務開始的快照，進而避免了不可重複讀，甚至是幻讀。

讀寫不沖突。但寫寫依賴有可能導緻寫操作失敗。其實這就是一個樂觀鎖。

寫失敗後需要事務重新執行，在應用開發上，這種模式沒有單純使用鎖的方式那麼友善。

7）SNAPSHOT ISOLATION(SSI)

隻有PostgreSQL實作了這種模式。和SI的差別在于它提供了額外的讀寫依賴檢測。

讀寫不沖突。但當系統發現讀寫依賴和實際的送出順序沖突時，終止事務并報錯。

進而實作了基于MVCC的嚴格的可串行化。

各個資料庫的并發事務和上面幾種實作模式的對于關系(近似的，細節上會有差異)如下:

SQL Server：

讀未送出：讀未送出

讀已送出(READ_COMMITTED_SNAPSHOT=OFF)：讀已送出(基于鎖)

可重複讀：可重複讀(基于鎖)

可串行化：可串行化(基于鎖)

讀已送出(READ_COMMITTED_SNAPSHOT=ON)：讀已送出(基于MVCC)

SNAPSHOT：SNAPSHOT ISOLATION(SI)

Oracle:

讀已送出：讀已送出(基于MVCC)

可串行化:  SNAPSHOT ISOLATION(SI)

PostgreSQL:

可重複讀：SNAPSHOT ISOLATION(SI)

可串行化: SNAPSHOT ISOLATION(SSI)

MySQL:

Symfoware

可重複讀(R_LOCK=YES)：可重複讀(基于鎖)

可串行化(R_LOCK=NO)：可串行化(基于鎖)