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页精彩内容：
|
评论暂时关闭