首页 > 代码库 > 数据库的读一致性分析

数据库的读一致性分析

前言

提起数据库的事务,我们就会想到ACID特性:

A:Atomicity 原子性    事务中包含的各种操作,要么一起成功,要么全部失败

C:Consistency 一致性  事务从一个一致性的状态转变成另一个一致性的状态 

I:Isolation 隔离性   各个事务之间的可见程度

D:Durability 持久性  数据库中的数据的改变应该是可以持久存储的

本篇博客将以MySQL为例分析数据库的读一致性。想分析清楚一致性,必先了解隔离级别。


数据库的隔离级别

在SQL标准中是定义了几种隔离级别的:


RU:Read Uncommitted(读取未提交内容)

RC:Read Committed(读取提交内容)

RR:Repeatable Read(可重读)

Serializable(可串行化)


Serializable这种隔离级别最高,若几个事务对同一份数据进行操作(即便是查询操作),它也针对每一个事务进行排序,严格按照排序进行事务的执行,显然解决了事务可能存在的冲突,但是会导致大量的超时以及锁竞争,因此在实际中大多是不会采用此种隔离级别的。

Oracle默认的隔离级别是:RC,并且Oracle只支持RC和Serializable这2种级别。RC,简单一句话,就是一个事务中只能看到另一个事务已经提交的数据的改变。那么RC会带来什么问题呢?在同一事务中,同一条SELECT语句可能会返回不一样的结果,即会产生  不可重复读。


MySQL默认的隔离级别是:RR。在该隔离级别下,可以保证在同一事务中,获取到的数据一致。这就是所谓的MySQL的读一致性,它的实现基于MVCC,后文中会分析。


RU可以让所有事务都读取到其他事务未提交的数据,会带来 脏读,同Serializable一样,在实际中,应用较少。



浅析MySQL MVCC原理

MVCC(MultiVersion Concurrency Control )多版本并发控制,可以简单的理解成为一个row lock的一个变种,只是在必要的时候加行锁。MySQL InnoDB的MVCC简单来讲是通过给表添加两列隐藏列来是实现的。一列是insert/update的时间,另一列是delete的时间,当然这里的时间并不是真正的时间,而是指SVN,即System Version Number,系统版本号,就是一个数字。每次开启一个事务,那么SVN号递增。



现在讨论在REPEATABLE READ下的MVCC实现:


SELECT


  • Innodb查找insert/update SVN小于等于当前事务的SVN的行,如果是小于,说明行之前就已经存在,如果是等于,说明这行是事务本身修改过的。

  • 行的删除时间列要么为空(说明该行未被删除)要么删除时间列的SVN大于当前事物的SVN(表示行是在事物开始之后被删除的)。


只有记录满足以上两条,才会被select语句返回!


这就是为何MYSQL在RR级别下,一个事务中是肯定读取不到“之后建立的”别的事务提交的数据,但是在本事务中更新的数据,可以读取出来的缘故!


INSERT


  • 插入之后以当前事务的SVN号更新创建列


DELETE


  • 删除之后,用当前SVN更新删除列


UPDATE


  • 更新创建列为当前SVN,同时更新删除列为update之前的创建列的SVN值


这样设计的优点是大部分的读操作都不用加锁了,而且是非阻塞的读取操作,使数据库操作简单,性能好,不足之处是增加了存储开销,需要额外的维护工作。


还是那句老话,用空间换取时间!




本文出自 “学海无涯 心境无限” 博客,请务必保留此出处http://zhangfengzhe.blog.51cto.com/8855103/1874662

数据库的读一致性分析