Mysql事务及隔离级别

在互联网公司应用开发工程中，事务处理是一个不可避免的问题。然而现在的网上博客，关于这块内容的讲解大部分都是晦涩难懂。今天，博主尝试用实验的方式让大家对数据库事务有个更为直观深入的理解。

事务（Transaction）及ACID

事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。
原子性(Atomicity) ：事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。
一致性(Consistent) ：在事务开始和完成时,数据都必须保持一致状态。
隔离性(Isolation) ：数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境中执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。
持久性(Durable) ：事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。
数据库原子性可以依靠日志来实现：将所有对数据的更新操作都写入到日志，如果一个事务中的一部分操作已经成功，但以后的操作，由于断电/系统奔溃/其它的软硬件错误而无法继续，则通过回溯日志，将已经成功的操作撤销，从而达到”全部操作失败“的目的。
最简单的场景是，数据库系统奔溃后重启，此时数据库处于一个不一致的状态，数据库系统必须先执行一个recovery的过程：读取日志进行REDO，重演所有已经执行成功但尚未写入到磁盘的操作，保证持久性。再对所有到奔溃时尚未成功提交的事务进行UNDO，撤销所有执行了一部分但尚未提交的操作，保证原子性。crash recovery结束后，数据库恢复到一致性状态，可以继续被使用。
简单的来说，一致性是事务的最终目的，原子性、隔离性和持久性都是为了实现一致性。

并发事务处理带来的问题

在实际应用场景中，对数据库的操作肯定是多线程并发访问的，并发场景下，数据一致性会面临诸多挑战。
更新丢失（Lost Update）
当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题，即最后的更新覆盖了由其他事务所做的更新。
脏读（Dirty Reads）
一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。
一句话：事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性要求。
不可重读（Non-Repeatable Reads）一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。
一句话：事务A读取到了事务B已经提交的修改数据，不符合隔离性。
幻读（Phantom Reads）
一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。
一句话：事务A读取到了事务B提交的新增数据，不符合隔离性。

事务隔离级别

“脏读”、“不可重复读”和“幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。

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

数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。
同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。

隔离级别实验分析

mysql数据库默认的隔离级别为REPEATABLE-READ。MySQL8.0之前查看当前数据库的事务隔离级别命令为:

show variables like 'tx_isolation';

而MySQL8.0 已删除原来的 tx_isolation ，改用 transaction_isolation：

show variables like 'transaction_isolation'\G;

设置事务隔离级别：

#8.0之前
set tx_isolation='REPEATABLE-READ';
#8.0
SET transaction_isolation = 'REPEATABLE-READ';

实验用的表如下，采用事物应用场景中最为常见的银行转账进行讲解。

DROP TABLE IF	EXISTS `account`;
CREATE TABLE `account` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '账户ID',
 `name` varchar(255) DEFAULT NULL COMMENT '姓名',
 `balance` int(11) DEFAULT NULL COMMENT '账户余额',
 PRIMARY KEY (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 INSERT INTO `account` (`name`, `balance`) VALUES ('zhangsan', '500');
 INSERT INTO `account` (`name`, `balance`) VALUES ('lisi','6000');
 INSERT INTO `account` (`name`, `balance`) VALUES ('wangwu', '2600');

1、读未提交：
（1）打开一个客户端A，并设置当前事务模式为read uncommitted（读未提交
），设置事物为手动提交，查询表account的初始值：

 SET transaction_isolation = 'READ-UNCOMMITTED';

2）打开另一个客户端B，更新表account，但不提交事物：

3）这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更
新的数据：

4) 一旦客户端B的事务因为某种原因如程序抛异常回滚，所有的操作都将会被撤销，那
客户端A查询到的数据其实就是脏数据:

5) 在客户端A执行更新语句update account set balance = balance - 50
where id =1，zhangsan的balance没有变成400，居然是450，是不是很奇怪，数据不
一致啊，如果你这么想就太天真了，在应用程序中，我们会用450-50=400，并
不知道其他会话回滚了，要想解决这个问题可以采用读已提交的隔离级别.

3、读已提交
（1）打开一个客户端A，并设置当前事务模式为read committed（读已提交），查询表account的所有记录：

SET transaction_isolation = 'READ-COMMITTED';

2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：

3）这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题

4）客户端B的事务提交
5）客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题.

4、可重复读
（1）打开一个客户端A，并设置当前事务模式为repeatable read，查询表account的所有记录

 SET transaction_isolation = 'REPEATABLE-READ';

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account并提交

3）在客户端A查询表account的所有记录，与步骤（1）查询结果一致，没有出现不可重复读的问题

4）在客户端A，接着执行update account set balance = balance - 50 where id = 1，balance没有变成400-50=350，zhangsan的balance值用的是步骤（2）中的350来算的，所以是300，数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC(multi-version concurrency control)机制，select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。