1.什么是事务

事务就是进行多个操作，要么同时执行成功，要么同时执行失败。

2.事务的特性 - ACID特性

2.1原子性Atomicity

原子性（Atomicity）：当前事务的操作要么同时成功，要么同时失败。原子性由undo log日志来实现。

在事务中，如果SQL进行了一个减库存的操作，例如由5扣减为2，在执行这个SQL语句时会使用undo log日志进行记录一个库存2到5的日志，如果失败抛出异常就会执行这条SQL语句。

2.2一致性Aconsistency

一致性（Consistency）：使用事务的最终目的，由其它3个特性以及业务代码正确逻辑来实现。

2.3隔离性Isolation

2.3.1什么是隔离性

隔离性（Isolation）：在事务并发执行时，他们内部的操作不能互相干扰，隔离性由MySQL的各种锁以及MVCC机制来实现。

在InnoDB引擎中，定义了四种隔离级别供我们使用，级别越高事务隔离性越好，但性能就越低，而隔离性是由MySQL的各种锁以及MVCC机制来实现的。

1.read uncommit（读未提交）：脏读。

2.read commit（读已提交）：不可重复读。

3.repeatable read（可重复读）：幻读。

4.serializable（串行）：解决上面所有问题，包括脏写。

MySQL的事务隔离性默认使用的是repeatable read（可重复读）

2.3.2读未提交

在read uncommit（读未提交）的隔离级别下，会产生脏读现象。

脏读：事务A读取到事务B已经修改但是尚未提交的数据。

一般不会使用这种隔离级别，这种隔离级别危机太多了。

2.3.3读已提交

在read commit（读已提交）的隔离级别下，会产生不可重复读的现象。

不可重复读的意思是，A事务在多次读取一个数据时，如果B事务在过程中对数据进行修改，并提交，A事务读到的数据会发生变化。

2.3.4可重复读

在repeatable read（可重复读）的隔离级别下，会产生幻读的现象。

执行的机制：在事务开启后，当执行了事务中第一条查询语句之后，MySQL中所有记录在事务中都有一条快照了，读取数据时都是读取快照中的数据，由此来实现的可重复读。

还需要注意的是，如果在当前事务对数据进行了修改，下次再读取的时候就会使用修改后的值，其他未修改的数据还是读取快照中的数据。并且修改的时候，不会用快照的数据，而是真实的数据。

由于该机制，A事务在执行完第一天查询语句后，读取的数据都是当时快照的数据，无论其他数据如何修改，在事务中读取的都是快照里的数据。

而且还会出现幻读的现象，幻读现象就是事务A读取到了事务B刚新增的数据。

有人说可重复读解决了幻读现象，也有人说可重复读没有解决幻读现象，这个是需要去分情况讨论的。现在同时启动A和B两个事务，假设A进行了一次查询操作，B事务在该表中进行了添加数据操作并提交了事务，这样A事务再去读取该表的数据时，由于A事务可重复读的机制，读取的数据是快照数据，则不会读取到B事务添加的数据，就不会产生幻读现象。但是如果A在开启事务后，查询了数据后，B事务去再去添加数据的时候，A事务再次去查询就会查询到B事务新增的数据，这样就会产生幻读现象。

2.3.5脏写现象

读未提交、读已提交、可重复读都可能会出现脏写现象。

脏写的意思是，由于隔离级别的问题，读取的数据是有问题的数据，但是还是在Java中对该数据进行处理后，并写入到了数据库中，此时写入的数据是个错的数据。

2.3.5.1读未提交出现脏写的原因

读未提交会出现脏写现象是因为，事务A和事务B一起开启了，事务B进行对数据修改了多次，但是事务B并没有进行提交，事务A此时读到了事务B未提交的数据，但是在事务A读取后，事务B进行了回滚，但是事务A用错误的数据，进行了操作，并更新到数据库，由此就会发生一次脏读事件。

2.3.5.2读已提交出现脏写的原因

读已提交会出现脏写现象是因为，事务A和事务B一起开启了，事务B进行对数据修改了多次，但是由于事务B没有进行提交，事务A读取到的数据永远是原始的数据，事务A对数据进行了操作，并提交，事务B此时用事务A未提交之前的数据进行修改，并更新到数据库，由此会发生一次脏读事件。

2.3.5.3可重复读出现脏写的原因

可重复读会出现脏写现象是因为，事务A和事务B一起开启了，事务A查询了一次数据，事务B对该数据进行了多次修改，并提交，事务A又读取了一次数据，读取到的数据是快照数据，并没有读取到事务B提交后的数据，并且事务A对该次读取的数据进行了修改，并提交到数据库，由此会发生一次脏读事件。

2.3.5.4解决脏写的方案：悲观锁

悲观锁解决方案，可以解决读未提交、读已提交和可重复读三种隔离级别的情况。

解决脏写可以采用的方法是采用悲观锁，每次更新的时候，使用SQL语句进行更新，而不是使用查询到的数据，在业务代码中进行修改后直接更新替换数据。

代码如下：

UPDATE account SET balance = balance + 500 WHERE id = 1;

2.3.5.5解决脏写的方案：乐观锁

乐观锁的解决方案，可以解决读未提交和读已提交两种隔离级别的方案。

解决脏写可以采用的方法是，给表格额外加一个version字段，每次更新的时候，WHERE筛选时加上自己上次查询出的版本号，如果更新成功就没事，更新失败就继续重新查询再更新，做一个自旋操作。

代码如下：

UPDATE account SET balance = balance WHERE id = 1 AND version = 1;

2.3.6串行化读取

在串行（serializable）情况下，这是最高的隔离级别，解决了以上所有的问题。

串行化的机制就是，当A事务开启后，其隔离级别是serializable时，A事务只要对某个数据表进行了查询操作，其他任务对该表的增加/更新操作都会被卡住，直到A事务提交/回滚。

这种方式解决了脏写和幻读的问题了，因为串行化对某个表进行读取操作后，其他针对该表的新增/删除/修改操作在串行化事务提交之前都会被阻塞住。

串行化的实现原理：

串行化的实现原理其实十分简单，在串行化事务中，执行是查询SQL语句会自动加一个读锁，由于读锁是共享的，当添加上这个读锁之后，对这个表再进行读取操作时，是没问题的，但是如果进行增加/修改/删除操作，就会被卡住，知道读锁释放。

查询的语句：

SELECT * FROM account WHERE id = 1;

该语句实际执行的时候，执行的SQL语句如下：

SELECT * FROM account WHERE id = 1 lock in share mode;

一般不会去使用串行化这种方案，因为这个方案的性能太差了，整体并发量低。

2.3.7读写锁

刚刚提到串行化隔离级别是使用读写锁实现的，所以现在具体介绍一下读写锁。

读锁（共享锁、S锁）：SELECT ... LOCK IN SHARE MODE；

读锁是共享的，多个事务可以同时读取同一个资源，但是不允许其它事务修改。

写锁（排它锁、X锁）：SELECT ... FOR UPDATE；

写锁是排他的，会阻塞其他的写锁和读锁，UPDATE、DELETE、INSERT都会加写锁。

2.4持久性Durability

一旦提交了事务，它对数据库的改变就应该是永久性的。持久性由redo log日志来实现。

MySQL保证持久性是通过redo log日志机制实现的，先来看MySQL更新一条数据的整体流程：

InnoDB引擎在执行一条写数据的操作的时候（假设现在进行的是更新操作），首先会从磁盘中加载需要修改的数据，再将数据写入到undo日志中（方便进行回滚），下一步并不是直接去修改表中的数据，而是将数据写入到redo日志中，最后才通过异步IO线程将数据更新到磁盘文件中。

之所以MySQL要做这个操作，完全是因为将数据写入到redo日志中进行的是磁盘顺序写的操作，而写入到表中的时候，由于多个表分布在多个文件中，无法进行磁盘顺序写，所以MySQL才会先将数据写入到redo日志中，对于机械硬盘来说，磁盘顺序写的性能提升很高，写入速度特别快。之所以要利用磁盘顺序写快速写入数据，是因为MySQL为了保证持久性，由于将数据写入到磁盘中是一个比较耗时的操作，如果中间出现突发情况，MySQL崩掉了，数据就会丢失，无法保证持久性，但是redo log是磁盘顺序写，性能非常高，所以可以保证持久性。

3.初识MVCC机制

3.1什么是MVVC机制

事务分为RNC，RC，RR，Serializable四种，一般来说不会使用Serializable隔离级别，因为该隔离级别虽然安全性很高，但是其性能堪忧，所以一般在真正的项目落地时，都会采用RC和RR这两种隔离级别，因为这两种隔离级别可以保障读写的并发，所有操作并非都是串行的，可以提高整体的并发量。

疑问点：RC和RR事务隔离级别在操作同一条数据的时候，是如何做到读写并发的呢？需不需要串行化呢？读写操作到底先执行读呢还是先执行写呢？

以上提到的疑问点就是读写并发问题，MySQL使用MVVC机制解决了读写并发问题。

MVVC（Multi-Version Concurrency Control）多版本并发控制，可以做到读写不阻塞，且避免了类似脏读这样的问题，主要是通过undo日志链来实现的。

SELECT操作时快照读（读取历史版本）

INSERT、UPDATE和DELETE是当前读（读取当前版本）

Read Commit（读已提交）：语句级快照。

Repeatable Read（可重复读）：事务级快照。

3.2MVVC机制的执行流程

MySQL在每张数据表中维护了两个字段，其中一个字段是trx_id，即最后操作这条数据的事务ID，还有一个字段是roll_pointer，这个字段是回滚指针，该指针指向的是回滚日志，如果事务进行了回滚操作，就会通过数据行中的roll_pointer回滚指针，找到回滚日志，完成回滚操作。

假设现在有一个数据表是account表，首先对account表进行一个插入操作，进行了插入操作之后，会讲操作account表的事务ID存储到数据行的trx_id字段中，并且会生成一个undo log日志，roll_pointer会指向该undo log。

又有一个事务对数据行进行了操作，将数据行中的balance进行修改为500，此时会将数据行的trx_id进行替换，并又生成了一个undo log，并将roll_pointer指向该undo log，最后事务完成了提交，完成提交后，会有一个commited标志指向该数据行。

假设现在启动了两个事务，事务A和事务B，事务A是RR可重复读隔离级别，事务B是RC读已提交隔离级别，此时两个事务同时执行查询该数据行的操作，最终查询出的数据均为500。

此时又有事务对该数据行进行了操作，将balance修改为800，并进行了提交。事务A再进行查询的时候，由于RR的机制导致器读取到的数据是500，事务B读取数据时，由于其永远读取的是已提交的数据，所以读取到的数据是800。

事务对该数据行再次进行了操作，将balance更新为1000但是没有提交，所以事务A和事务事务B再进行查询时保持原有数据不变。

3.3undo日志链

从整个MVVC机制的执行流程中可以发现，无论是查询，回滚，是否提交等操作都是通过该链完成的，这样不仅节省了空间（不是每一个日志都要生成一个undo log），还保证了读写的并发性，提高了整体的性能。

4.如何选择适合隔离级别

对于MySQL中四种隔离界别，RNC读未提交，RC读已提交，RR可重复读，Serilizable串行化，这四种隔离级别，性能从高到低，安全性从低到高，一般在实际生产落地的环境中不会使用到RNC读未提交，因为这种方式虽然性能很高，但是安全性特别差，会出现脏读现象，所以一般不会使用这种隔离级别。对于Serializable串行化隔离级别，一般在生产环境中也不会使用这种隔离级别，因为这种隔离级别安全性虽然很高，但是性能实在是太差了。

在开发时，一般只会采用RC读已提交和RR可重复读这两种隔离级别。对于一些并发量要求不是巨大的系统，一般都是直接采用MySQL默认的隔离级别RR可重复读即可，但是对于一些互联网公司而言，如果需要很高的性能，会考虑采用RC读已提交这种隔离级别，因为这种隔离级别只会对写进行加事务，RR这种隔离级别会对读写都会加事务，所以相对来说RC的性能会更高一些。

在实际事务选型时，需要根据当前业务场景进行分析选型。需要对读操作加事务的时候，可以采用RR事务隔离级别来保证事务内读数据时，读取出的数据在同一时间维度。如果不需要对读操作进行加事务的操作，可以根据需要考虑使用RC事务级别。