目录
Mysql在读已提交和可重复读隔离级别下确保事务较高的隔离性,就是靠MVCC(Multi-Version Concurrency Control)机制来保证的,对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性,避免了频繁加锁互斥,而在串行化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的。
MVCC具体通过 3个字段、undo日志版本链、read view机制来实现的。
3个字段
DB_TRX_ID事务ID:最后一个对数据插入或者更新的事务 ID。
DB_ROLL_PTR回滚指针:配合undo日志,指向上一个旧版本。
DB_ROW_ID自增ID:如果没有创建聚集索引,则会偷偷建一个自增ID。
undo日志版本链
一行数据被多个事务依次修改过后,Mysql会保留修改前的数据undo回滚日志,并且用trx_id和roll_ptr把这些undo日志串联起来形成一个历史记录版本链。
id | name | updatetime | TRX_ID | ROLL_PTR |
---|---|---|---|---|
3 | Lisi5 | 13:00:05 | 321005 | ↓(指向底下一行) |
3 | Lisi4 | 13:00:04 | 321004 | ↓(指向底下一行) |
3 | Lisi3 | 13:00:03 | 321003 | ↓(指向底下一行) |
3 | Lisi2 | 13:00:02 | 321002 | ↓ (指向底下一行) |
3 | Lisi1 | 13:00:01 | 321001 |
Read view
在可重复读隔离级别,当事务开启时,执行任何查询sql时会生成当前事务的一致性视图read-view,该视图在事务结束之前都不会变化 (如果是读已提交隔离级别在每次执行查询sql时都会重新生成),这个视图由组成下面两个组成。
1)执行查询时所有未提交事务id数组(数组里最小的id为min_id)
2)已创建的最大事务id(max_id)
MVCC查询机制
事务里的任何sql查询结果都需要从对应undo日志版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果。过程具体为:
1. 如果 trx_id 落在( trx_id<min_id ),表示这个版本是已提交的事务生成的,这个数据是可见的;
2. 如果 trx_id 落在( trx_id>max_id ),表示这个版本是由将来启动的事务生成的,是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的);
3. 如果 trx_id 落在(min_id <= trx_id <= max_id),
a. 若 trx_id 在视图数组中,表示这个版本是由还没提交的事务生成的,不可见(若 row 的 trx_id 就是当前自己的事务是可见的);
b. 若 trx_id 不在视图数组中,表示这个版本是已经提交了的事务生成的,可见。
对于删除的情况可以认为是update的特殊情况,会将版本链上最新的数据复制一份,然后将trx_id修改成删除操作的trx_id,同时在该条记录的头信息(record header)里的(deleted_flag)标记位写上true,来表示当前记录已经被删除,在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true,意味着记录已被删除,则不返回数据。
注意:begin/start transaction 命令并不是一个事务的起点,在执行到它们之后的第一个修改操作InnoDB表的语句,事务才真正启动,才会向mysql申请事务id,mysql内部是严格按照事务的启动顺序来分配事务id的。
总结
MVCC机制的实现就是通过read-view与undo版本链比对机制,使得不同的事务会根据数据版本链对比规则读取同一条数据在版本链上的不同版本数据。