目录
MySql事务简介
ACID简介
ACID原理
事务隔离级别
Mysql的锁机制
事务底层实现原理
Mysql中什么时候会加锁
MVCC(多版本并发控制)原理
快照(视图)在MVCC底层工作原理
快照遵循原则
两个事务执行写操作,如何保证并发
MySql事务简介
数据库事务是指一组sql语句组成的数据库逻辑单元,在这组的sql操作中,要么全部执行成功,要么全部执行失败;
例如:转账,事务A中要进行转账,那么转出的账号要扣钱,转入的账号要加钱,这两个操作必须同时执行成功,为了确保数据的一致性。
ACID简介
MySql中事务的四大特征:原子性(Atomicity)、一致性(Consistent)、隔离性(Isalotion)、持久性(Durable),简称为ACID。
原子性:指事务的原子性操作,对数据的修改要么全部执行成功,要么全部失败,实现事务的原子性,是基于日志的Redo/Undo机制。
一致性:指执行事务前后的状态要一致,可以理解为数据一致性。
隔离性:侧重指事务之间相互隔离,不受影响,这个与事务设置的隔离级别有密切关系。
持久性:指一个事务提交后,这个事务的状态会被持久化到数据库中,也就是事务提交,对数据的新增、更新将会持久化到数据库中。
注:原子性、隔离性、持久性都是为了保障一致性而存在的,一致性也是最终的目的。
Mysql怎么保证一致性的?
从数据库层面,数据库通过原子性、隔离性、持久性来保证一致性。也就是说ACID四大特性之中,C(一致性)是目的,A(原子性)、I(隔离性)、D(持久性)是手段,是为了保证一致性,数据库提供的手段。数据库必须要实现AID三大特性,才有可能实现一致性。
从应用层面,通过代码判断数据库数据是否有效,然后决定回滚还是提交数据。
ACID原理
Redo/Undo机制比较简单,它们将所有对数据的更新操作都写到日志中。
Redo log用来记录某数据块被修改后的值,可以用来恢复未写入 data file 的已成功事务更新的数据;
Undo log是用来记录数据更新前的值,保证数据更新失败能够回滚。假如数据库在执行的过程中,不小心崩了,可以通过该日志的方式,回滚之前已经执行成功的操作,实现事务的一致性。
如:某个时刻数据库崩溃,在崩溃之前有事务A和事务B在执行,事务A已经提交,而事务B还未提交。当数据库重启进行 crash-recovery 时,就会通过Redo log将已经提交事务的更改写到数据文件,而还没有提交的就通过Undo log进行roll back。
事务隔离级别
Mysql中事务的隔离级别分为四大等级,读未提交(READ UNCOMMITTED)、读提交 (READ COMMITTED)、可重复读 (REPEATABLE READ)、串行化 (SERIALIZABLE)。
读未提交:会读到另一个事务的未提交的数据,产生脏读问题。
读提交:则解决了脏读的,出现了不可重复读,即在一个事务任意时刻读到的数据可能不一样,可能会受到其它事务对数据修改提交后的影响,一般是对于update的操作。
可重复读:解决了之前不可重复读和脏读的问题,但是由带来了幻读的问题,幻读一般是针对inser操作。
如:第一个事务查询一个User表id=100发现不存在该数据行,这时第二个事务又进来了,新增了一条id=100的数据行并且提交了事务。这时第一个事务新增一条id=100的数据行会报主键冲突,第一个事务再select一下,发现id=100数据行已经存在,这就是幻读。
读未提交演示:
首先创建一个User表,最为一个测试表,测试表里面有三个字段,并插入两条测试数据。
CREATE TABLE User (
id INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(20),
age INT DEFAULT 0
) ENGINE=InnoDB DEFAULT CHARSET=gb2312;
INSERT INTO `user` VALUES (1, 'zhangsan', 23);
INSERT INTO `user` VALUES (2, 'lisi', 20);
在Mysql中可以先查询一下他的默认隔离级别(select @@tx_isolation;),可以看出Mysql的默认隔离级别是REPEATABLE-READ
。
先来演示一下读未提交,先把默认的隔离级别修改为READ UNCOMMITTED
。
set session TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
设置隔离级别的语句中set global transaction isolation level read uncommitted,这里的global也可以换成session,global表示全局的,而session表示当前会话,也就是当前窗口有效。
然后是开启事务,Mysql中开启事务有两种方式 begin/start transaction
,最后提交事务执行commit,或者回滚事务rollback。在执行 begin/start transaction
命令,它们并不是一个事务的起点,在执行完它们后的第一个sql语句,才表示事务真正的启动 。
这里直接打开两个新的窗口,同时开启事务,在第一个窗口先update一个id=1的数据行修改name,执行成功。
然后再第二个窗口执行两次的查询,分别是窗口一update之前的查询和update之后的查询。
第一个session产生的未提交的事务的状态就会直接影响到第二sesison,也就是脏读。
读提交:
对于读提交也是一样的,开启事务后,第一个事务先执行查询数据,然后第二个session执行update操作,但是还没有commit,这是第一个session再次select,数据并没有改变,再第二个session执行commit之后,第一个session再次select就是改变后的数据了。
这样第一个事务的查询结果就会收到第二事务的影响,这个也就是产生不可重复读的问题。(这儿就不做演示了)
流程图如下:
这个是读提交的时间轴图,读未提交的时间轴图,原理也一样的,第二个select的时候数据就已经改变了。
可重复读:
将两个session开启为REPEATABLE READ
,同时开启事务,在第一个事务中先select,然后在第二个事务里面update数据行,可以发现即使第二个事务已经commit,第一个事务再次select数据也还是没有改变,这就解决了不可重复读的问题。
这里有个不同的地方就是在Mysql中,默认的不可重复读个隔离级别也解决了幻读的问题。
最后的串行化,样式步骤也是一样的,结果也和Mysql中默认的个可重复读隔离级别的结果一样,串行化的执行流程相当于把事务的执行过程变为顺序执行,我这边就不再做演示了。
注:这四大等级从上到下,隔离的效果是逐渐增强,但是性能却是越来越差。
Mysql的锁机制
在Mysql中的锁可以分为分享锁/读锁(Shared Locks)、排他锁/写锁(Exclusive Locks) 、间隙锁、行锁(Record Locks)、表锁。
在四个隔离级别中加锁肯定是要消耗性能的,而读未提交是没有加任何锁的,所以对于它来说也就是没有隔离的效果,所以它的性能也是最好的。
对于串行化加的是一把大锁,读的时候加共享锁,不能写,写的时候,加的是排它锁,阻塞其它事务的写入和读取,若是其它的事务长时间不能写入就会直接报超时,所以它的性能也是最差的,对于它来就没有什么并发性可言。
对于读提交和可重复读,他们俩的实现是兼顾解决数据问题,然后又要有一定的并发行,所以在实现上锁机制会比串行化优化很多,提高并发性,所以性能也会比较好。
他们俩的底层实现采用的是MVCC(多版本并发控制)方式进行实现。
事务底层实现原理
共享锁:是针对同一份数据,多个读操作可以同时进行,简单来说即读加锁,不能写并且可并行读;排他锁针对写操作,假如当前写操作没有完成,那么它会阻断其它的写锁和读锁,即写加锁,其它读写都阻塞 。
行锁和表锁:是从锁的粒度上进行划分的,行锁锁定当前数据行,锁的粒度小,加锁慢,发生锁冲突的概率小,并发度高,行锁也是MyISAM和InnoDB的区别之一,InnoDB支持行锁并且支持事务 。表锁则锁的粒度大,加锁快,开销小,但是锁冲突的概率大,并发度低。
间隙锁:则分为两种:Gap Locks
和Next-Key Locks
。Gap Locks会锁住两个索引之间的区间,比如select * from User where id>3 and id<5 for update,就会在区间(3,5)之间加上Gap Locks。
Next-Key Locks是Gap Locks+Record Locks形成闭区间锁select * from User where id>=3 and id=<5 for update,就会在区间[3,5]之间加上Next-Key Locks。
Mysql中什么时候会加锁
在数据库的增、删、改、查中,只有增、删、改才会加上排它锁,而只是查询并不会加锁,只能通过在select语句后显式加lock in share mode或者for update来加共享锁或者排它锁。
MVCC(多版本并发控制)原理
在实现MVCC时用到了一致性视图,用于支持读提交和可重复读的实现。在实现可重复读的隔离级别,只需要在事务开始的时候创建一致性视图,也叫做快照,之后的查询里都共用这个一致性视图,后续的事务对数据的更改是对当前事务是不可见的,这样就实现了可重复读。而读提交,每一个语句执行前都会重新计算出一个新的视图,这个也是可重复读和读提交在MVCC实现层面上的区别。
快照(视图)在MVCC底层工作原理
在InnoDB 中每一个事务都有一个自己的事务id,并且是唯一的,递增的 。对于Mysql中的每一个数据行都有可能存在多个版本,在每次事务更新数据的时候,都会生成一个新的数据版本,并且把自己的数据id赋值给当前版本的row trx_id。
如图中所示,假如三个事务更新了同一行数据,那么就会有对应的三个数据版本。实际上版本1、版本2并非实际物理存在的,而图中的U1和U2实际就是undo log,这v1和v2版本是根据当前v3和undo log计算出来的。
快照遵循原则
对于一个事务视图来说除了对自己更新的总是可见,另外还有三种情况:版本未提交的,都是不可见的;版本已经提交,但是是在创建视图之后提交的也是不可见的;版本已经提交,若是在创建视图之前提交的是可见的。
两个事务执行写操作,如何保证并发
假如事务1和事务2都要执行update操作,事务1先update数据行的时候,先回获取行锁,锁定数据,当事务2要进行update操作的时候,也会取获取该数据行的行锁,但是已经被事务1占有,事务2只能wait。若是事务1长时间没有释放锁,事务2就会出现超时异常 。