MySQL多版本并发控制分析
MySQL多版本并发控制分析
背景:
之前面试被问到这么一个问题,数据库两个transaction,当transaction1在update某一行的时候,transaction2在select的时候会不会block。我以前用MySQL做过测试,印象是可以,但是面试官提出质疑,今天我用MySQL验证这个问题的仔细研究了一下MySQL的后台实现,后来再网上发现了下面这篇文章非常就转过来,不过文中有些地方逻辑上好像不太对,我没有时间去读MySQL源代码,就根据实际结果给出自己的推测,如果大家有明确答案请共享之。
我先把文中感觉不对的地方我自己总结的放出来(标红的为我的猜测),大家可以先看正文,然后再回头看我的总结:
- READ_UNCOMMITTED
读未提交时,读事务直接读取主记录,无论更新事务是否完成 - READ_COMMITTED
读提交时,读事务每次检查主记录上有没有锁,如果没有锁就读取主记录;如果有锁,就读取undo log中最近的版本。这样每次读到的都是最新COMMITTED的数据。因此两次对同一字段的读可能读到不同的数据(幻读),但能保证每次都读到最新的数据。 - REPEATABLE_READ
第一次读的时候检查主记录上有没有锁,如果没有锁就读取主记录;如果有锁,就读取undo log中最近的版本。我猜测update的时候创建新的记录,然后将原先主记录内容拷贝到当前主记录中,原先的主记录就变为最新的undo log。以后每次都读取第一次读的版本,这样保证不会产生幻读,但可能读不到最新的数据 - SERIALIZABLE
锁表,读写相互阻塞,使用较少
正文链接如下:
Mysql到底是怎么实现MVCC的?这个问题无数人都在问,但google中并无答案,本文尝试从Mysql源码中寻找答案。
在Mysql中MVCC是在Innodb存储引擎中得到支持的,Innodb为每行记录都实现了三个隐藏字段:
- 6字节的事务ID(
DB_TRX_ID
) - 7字节的回滚指针(DB_ROLL_PTR)
- 隐藏的ID
1. Innodb的事务相关概念
为了支持事务,Innbodb引入了下面几个概念:- redo log
redo log就是保存执行的SQL语句到一个指定的Log文件,当Mysql执行recovery时重新执行redo log记录的SQL操作即可。当客户端执行每条SQL(更新语句)时,redo log会被首先写入log buffer;当客户端执行COMMIT命令时,log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在,即Innodb的log文件。 - undo log
与redo log相反,undo log是为回滚而用,具体内容就是copy事务前的数据库内容(行)到undo buffer,在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样,也是环形缓冲,但当缓冲满的时候,undo buffer中的内容会也会被刷新到磁盘;与redo log不同的是,磁盘上不存在单独的undo log文件,所有的undo log均存放在主ibd数据文件中(表空间),即使客户端设置了每表一个数据文件也是如此。 - rollback segment
回滚段这个概念来自Oracle的事物模型,在Innodb中,undo log被划分为多个段,具体某行的undo log就保存在某个段中,称为回滚段。可以认为undo log和回滚段是同一意思。 - 锁
Innodb提供了基于行的锁,如果行的数量非常大,则在高并发下锁的数量也可能会比较大,据Innodb文档说,Innodb对锁进行了空间有效优化,即使并发量高也不会导致内存耗尽。
对行的锁有分两种:排他锁、共享锁。共享锁针对对,排他锁针对写,完全等同读写锁的概念。如果某个事务在更新某行(排他锁),则其他事物无论是读还是写本行都必须等待;如果某个事物读某行(共享锁),则其他读的事物无需等待,而写事物则需等待。通过共享锁,保证了多读之间的无等待性,但是锁的应用又依赖Mysql的事务隔离级别。 - 隔离级别
隔离级别用来限制事务直接的交互程度,目前有几个工业标准:
- READ_UNCOMMITTED:脏读
- READ_COMMITTED:读提交
- REPEATABLE_READ:重复读
- SERIALIZABLE:串行化
Innodb对四种类型都支持,脏读和串行化应用场景不多,读提交、重复读用的比较广泛,后面会介绍其实现方式。
接下来请看第2页精彩内容:
|
评论暂时关闭