【Mysql】事务原理与优化最佳实践（四）

前言

我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制、日志机制，用一整套机制来解决多事务并发问题。

事务

一组操作要么全部成功，要么全部失败，目的是为了保证数据的最终一致性
在这里插入图片描述
如上图操作:A向B转账1000，实际上就是A减少1000，B增加1000，不存在A减少了，B没增加。B增加了，A没减少。

事务ACID特性

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

比如下单操作，下单订单后需要减少库存，他们应该是同时的，比如说我们下单成功了，库存减少失败了，此时下单功能所做的操作应该需要进行回滚。

一致性(Consistency)：使用事务的最终目的，由其他三个特性以及业务代码证券逻辑来实现。

还下单的操作，比如下面代码库存的减少可能因为我的代码的不严谨使用try-catch从而没法达到一致性。
public void createOrder(){//创建订单try{//减少库存}catch(Exception e){}
}

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

这部分比较重要，单独说。

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

这个就比较好理解哈

事务隔离性

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

read uncommit（读未提交）：脏读
read commit（读已提交）：不可重复读
repeatable read（可重复读）：幻读
serializable（串行）：解决上面所以问题，包括脏写

在工作中，我们用的大多是repeatable read和read commit，一些大厂用的比较多的是read commit，一些软件公司用的比较多的是repeatable read，可能实际上我们根本不关注这些隔离级别，就是使用的默认的repeatable read

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

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

查看当前数据库的事物隔离级别：

show variables like 'tx_isolation';

设置事物隔离级别：

set tx_isolation = 'REPEATABLES-READ';

Mysq默认的事物隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔离级别，如果Spring设置了就用已经设置的隔离级别，下面我们来看一下隔离级别的案例分析。

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

 set tx_isolation='read‐uncommitted';

在这里插入图片描述
在客户端A的事务提交之前，打开另一个客户端B，更新表account：

在这里插入图片描述
这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：

一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：

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

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

set tx_isolation='read‐committed';

在这里插入图片描述
在客户端A的事务提交之前，打开另一个客户端B，更新表account：

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

客户端B的事务提交

客户端A执行与上一步相同的查询，结果与上一步不一致，即产生了不可重复读的问题
在这里插入图片描述

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

set tx_isolation='repeatable‐read';

在这里插入图片描述
在客户端A的事务提交之前，打开另一个客户端B，更新表account并提交

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

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

在客户端A查询表account的所有记录，没有查出新增数据，所以没有出现幻读

验证幻读
在客户端A执行update account set balance=888 where id = 4；能更新成功，再次查询能查到客户端B新增的数据
在这里插入图片描述

串行化:打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值

set tx_isolation='serializable';

在这里插入图片描述
打开一个客户端B，并设置当前事务模式为serializable，更新相同的id为1的记录会被阻塞等待，更新id为2的记录可以成功，说明在串行模式下innodb的查询也会被加上行锁，如果查询的记录不存在会给这条不存在的记录加上锁(这种是间隙锁，后面会详细讲)。如果客户端A执行的是一个范围查询，那么该范围内的所有行包括每行记录所在的间隙区间范围都会被加锁。此时如果客户端B在该范围内插入数据都会被阻塞，所以就避免了幻读。这种隔离级别并发性极低，开发中很少会用

在这里插入图片描述

事务问题定位

1 #查询执行时间超过1秒的事务，详细的定位问题方法后面讲完锁课程后会一起讲解 
2 SELECT  *  FROM  information_schema.innodb_trx  WHERE  TIME_TO_SEC( timediff( now( ), trx_started ) ) > 1; #强制结束事务 10 kill 事务对应的线程id(就是上面语句查出结果里的trx_mysql_thread_id字段的值)