Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2900683
  • 博文数量: 199
  • 博客积分: 1400
  • 博客等级: 上尉
  • 技术积分: 4126
  • 用 户 组: 普通用户
  • 注册时间: 2008-07-06 19:06
个人简介

半个PostgreSQL DBA,热衷于数据库相关的技术。我的ppt分享https://pan.baidu.com/s/1eRQsdAa https://github.com/chenhuajun https://chenhuajun.github.io

文章分类

全部博文(199)

文章存档

2020年(5)

2019年(1)

2018年(12)

2017年(23)

2016年(43)

2015年(51)

2014年(27)

2013年(21)

2011年(1)

2010年(4)

2009年(5)

2008年(6)

分类: Mysql/postgreSQL

2013-09-20 00:54:12

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

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):可串行化(基于锁)





阅读(3043) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~