mysql之事务处理

就是把一组SQL当成一个整体，看成是一个事务。

要求事务中的所有SQL，要么全部执行成功。要么全部不生效。这种机制就叫事务处理机制。

事务处理功能只有在innodb存储引擎下才支持。

只需要使用3个SQL就可以使用事务处理功能了。

1. Start transaction，启动事务处理

2. Commit，成功的情况下，提交事务并结束此次事务

3. Rollback，失败的情况下，进行事务的回滚，撤消之前所有的操作，并结束此次事务

使用transaction方式的事务处理

我们建立一个数据表，插入一些数据，模拟付款操作

在没有事务处理的情况下

有事务处理功能把持的方式

上面是讲出错的情况的处理

下面看一下正常执行的过程

我们发现有一个客户端启动事务后，第一步执行了一个减少钱数的操作，第一个客户端自动看到钱数减少了，而其它客户端看到还是原来的钱数

总结：

1. 事务是有隔离性的，一个事务在执行过程中，只有自己能够看到执行的每一步，而其它的客户端是看不到的

2. 事务处理情况下，MYSQL把SQL分成了二步：执行+提交，事务未完成时，只执行，不提交。当事务中所有SQL都执行成功时，才一起提交。如果事务中某句SQL执行失败，则进行回滚，之前执行的SQL不会进行提交。

3.  事务使用的记录会在事务未完成前锁定，以保证事务的正确性

再给另外一个用户加钱，其它客户端还是看不到变化

事务中的所有SQL都执行成功，使用commit进行提交

使用autocommit系统参数进行事务处理

查看客户下的系统变量，其中有一个叫autocommit参数（自动提交）

此参数默认情况下为on，代表此时所有的SQL都是执行并同时提交的

我们可以修改这个参数为off，此时客户端的SQL就变成只执行，先不提交了

此时是不是就相当于进入了事务处理状态了。

我们自行控制此参数，模拟事务处理

1.      将autocommit设为off

2．减少ID=1的用户的钱，发现其它客户端确实看不到变化，证明是在事务处理状态

再给另一个用户加钱，情况一样

1.      将autocommit设置回on

此时每个客户端看到的数据就一样了。证明事务处理已经结束了，并且第一个客户已经把执行结果时行了提交。

总结：事务处理的核心就是把SQL的执行过程分成了：执行+提交

思考：在使用autocommit参数方式的事务处理时

autocommit=0，此时是在事务状态中。

如果这种情况下，我们使用start transactiona或commit或rollback会发生什么？

重要：如果在使用autocommit模拟事务时，使用了上面3句就会出现

结束当前的事务，又开始了一个新的事务处理

直到autocommit又变回1时才真正结束了整个事务。

如果事务失败，则使用rollback回滚，再把autocommit=1结束

事务处理的ACID特点

A 原子性，事务中的SQL是一个整体，不可分割

C 一致性，事务中的SQL要么全都执行成功，要么全都失效

I 隔离性，不同事务之间是隔离的，互相看不到的

D 持久性，事务处理的结果要能够写入到真实的数据表

事务处理中的日志和数据文件

我们在执行事务处理时，执行的结果并不是直接写入到数据表，而只是写入日志文件中，当事务中所有SQL都成功并使用commit提交后，才真正写入到表空间数据文件中。

本质：还是执行+提交