MySql事务简介、锁机制及底层原理

目录

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就会出现超时异常 。