就是把一组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提交后,才真正写入到表空间数据文件中。
本质:还是执行+提交