MYSQL事务隔离级别及MVCC机制

MYSQL事务隔离级别及MVCC机制

  • 事务及其ACID属性
  • 并发事务带来的问题
  • 事务隔离级别
  • 锁分类
  • MYSAM和InnoDB的最大区别
  • MVCC多并发版本控制机制
      • undo日志版本链和read view机制

事务及其ACID属性

事务是由一组sql组成的逻辑处理单元,事务具有以下4个属性,一般简称为ACID:

  • 原子性(Atomicity):事务是一个整体的原子操作单元,要么全部修改,要么全部不修改;
  • 一致性(Consistent):要求事务的单元操作要么全部执行成功,要么全部执行失败;
  • 隔离性(Isolation):保证多个事务之间的数据是独立隔离的,不受其他事务的影响;
  • 持久性(Durable):事务完成之后对他的数据是永久保存的。

并发事务带来的问题

  • 脏写:两个事务同时对一条数据操作,后提交的数据覆盖了先提交的数据;
  • 脏读:一个事务操作了一条数据,还未提交,另一个事务读取到了这条数数据;
  • 不可重复读:在一个事务里面获取一条数据,另一个事务对这条数据做了修改并提交,第一个事务再获取这条数据时是已经被修改了;
  • 幻读:一个事务通过一个条件查询数据,另一个事务对着数据进行了删除或新增,第一个事务再次获取这个事务时,数据的条数不一样了;

事务隔离级别

事务隔离级别 脏读 不可重复读 幻读
读未提交
读已提交
可重复读
可串行化

锁分类

  • 从性能上分类:乐观锁和悲观锁;
  • 从功能上分类:读锁和写锁;
  • 从锁力度上分类:表锁和行锁;

MYSAM和InnoDB的最大区别

  • MYSAM支持读锁和写锁(读锁会限制写,但不会限制读,写锁会全部限制);
  • InnoDB支持行锁(读锁和写锁是锁整张表,而行锁只是锁一行数据,力度小,开销大);
  • InnoDB支持事务(默认是可重复读),MYSAM是不支持事务的;

MVCC多并发版本控制机制

隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的,对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性,避免了频繁加锁互斥,而在串行化隔离级别为了保证较高的隔离性是通过将所有操
作加锁互斥来实现的。
Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制。

undo日志版本链和read view机制

undo日志版本链是指一行数据被多个事务依次修改过后,在每个事务修改完后,Mysql会保留修改前的数据undo回滚日志,并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链:
MYSQL事务隔离级别及MVCC机制_第1张图片
在可重复读隔离级别,当事务开启,执行任何查询sql时会生成当前事务的一致性视图read-view,该视图在事务结束
之前都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成),这个视图由执行查询时所有未提交事
务id数组(数组里最小的id为min_id)和已创建的最大事务id(max_id)组成,事务里的任何sql查询结果需要从对应
版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果。
版本链比对规则:

  1. 如果 row 的 trx_id 落在绿色部分( trx_id
  2. 如果 row 的 trx_id 落在红色部分( trx_id>max_id ),表示这个版本是由将来启动的事务生成的,是不可见的(若
    row 的 trx_id 就是当前自己的事务是可见的);3. 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id),那就包括两种情况
    a. 若 row 的 trx_id 在视图数组中,表示这个版本是由还没提交的事务生成的,不可见(若 row 的 trx_id 就是当前自
    己的事务是可见的);
    b. 若 row 的 trx_id 不在视图数组中,表示这个版本是已经提交了的事务生成的,可见。

你可能感兴趣的:(mysql索引)