前言
我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增 删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。 这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了事 务隔离机制、锁机制、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字段的值)
大事务的影响
- 并发情况下，数据库连接池容易被撑爆
- 锁定太多的数据，造成大量的阻塞和锁超时
- 执行时间长，容易造成主从延迟
- 回滚所需要的时间比较长
- undo log膨胀
- 容易导致死锁
事务优化
- 将查询等数据准备操作放到事务外
- 事务中避免远程调用，远程调用要设置超时，防止事务等待时间太久
- 事务中避免一次性处理太多数据，可以拆分成多个事务分次处理
- 更新等涉及加锁的操作尽可能放在事务靠后的位置
- 能异步处理的尽量异步处理
- 应用侧(业务代码)保证数据一致性，非事务执行
