并发事务下各数据库外部表现实测之六（总结篇）

根据并发事务的实现方式和外部表现，可以归纳出下面几种事务处理模式（近似的）。

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:
读已提交：读已提交(基于MVCC)
可重复读：SNAPSHOT ISOLATION(SI)
可串行化: SNAPSHOT ISOLATION(SSI)

MySQL:
读未提交：读未提交
读已提交：读已提交(基于MVCC)
可重复读：SNAPSHOT ISOLATION(SI)
可串行化：可串行化(基于锁)

Symfoware
读未提交：读未提交
读已提交(READ_COMMITTED_SNAPSHOT=OFF)：读已提交(基于锁)
可重复读(R_LOCK=YES)：可重复读(基于锁)
可串行化(R_LOCK=NO)：可串行化(基于锁)