重温事务的概念
为什么用事务、事务是什么
我们规定了，做一件事情，只有成功和失败!
用个很经典的例子举例：银行转账，a向b转账十万，能不能发生一遍付钱一边没收钱的情况？
现实中一定是a和b同时成功或者失败，不能出现一边成功另一边失败的情景，这就是事务的简单例子。
那么由这个例子我们想想事务其实是为了保证什么？
假如：
- 张三问罗老师借钱，借了钱没写借据。
- 这是做了事情，但是没有依据，就算做成功了，也没办法证明。突出借据的重要性（持久性） redolog
- 张三问罗老师借钱，罗老师同意了，可是张三不想借了。
这是事情做成功了，关键点在于，我可不可以反悔。（张三去决定）突出回滚的重要性（原子性）undo log
所以**事务其实就是想要做的事情是一个整体！**事务的存在目的就是为了事情能够正确成功的执行。
如果以数据库的角度去看：
在关系型数据库中，事务其实就是【一组原子性的sql】或者说一个独立不可分割的工作单元，如果数据库引擎能成功的对数据库引用该组查询的全部语句，那么就执行该组查询，如果其中有任何一条语句因为崩溃或者其他原因无法执行，那么所有的语句都不会执行，也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。
那么刚才那个转账的例子，让我们去写一个事务，应该怎么写？
查询a账户的余额是否大于10w块钱从a账户余额中减去10w块钱在b账户余额中增加10w块钱
怎么用事务
还记得怎么写事务的sql语句吗？
--开启一个事务 begin;--等价于 start transaction; --执行我们需要的sql --提交事务 commit; --回滚事务 rollback;
我们来模拟一下a的两个账户（cmbc银行、icbc银行）之间转账的事务
# 开启转账事务 begin; select balance from bank_cmbc where user_name = 'a的cmbc银行账户'; # 这里需要判断余额 是否大于等于 10w update bank_cmbc set balance = balance - 100000 where user'a的cmbc银行账户'; update bank_icbc set balance = balance + 100000 where user'a的icbc银行账户'; # 这里当然还需要记录 记录表 日志表 转账记录表 等 select * from bank_cmbc; select * from bank_icbc; --提交 commit; --或者回滚 rollback; # bank_cmbc 里的余额会减去10w 然后 bank_icbc账户增加10w， # 这个就是我们事务的具体使用场景了，要么全部成功要么全部失败！
我能不能只提交一部分事务，一部分事务不提交呢？
也可以，使用savepoint，但是呢，要记得提交。
begin; select balance from bank_cmbc where user_name = 'a的cmbc银行账户'; # 这里需要判断余额 是否大于等于 10w update bank_cmbc set balance = balance - 100000 where user_name ='a的cmbc银行账户'; savepoint a;--设置回滚点 update bank_icbc set balance = balance + 100000 where user_name ='a的icbc银行账户'; # 这里当然还需要记录 记录表 日志表 转账记录表 等 # 回滚到保存点 rollback to a; select * from bank_cmbc; select * from bank_icbc; commit;
# 这个时候我们的记录是多少？ # 我们看一下 在savepoint 之前的语句都能正确提交，savepoint之后的语句因为我们手动回滚了他们是没有被更改成的，这 # 就是savepoint的作用，他能够在一个事务里开启一个嵌套事务。主事务和嵌套事务属于同一个事务，嵌套事务出错回滚不会影响主事务，主事务回滚会将嵌套事务一起回滚。主事务提交嵌套事务也会跟着提交。
问一个面试官可能会问到的问题，我们知道多条sql语句开启的时候，能保证全部成功、或者全部失败。那么单条sql语句有没有事务呢？
其实每个语句都是原子性的，他们被隐式的加入了 begin; start transaction 开启事务，并commit;
就好像：
begin; update bank cmbc set balance = balance + 100000 where user_name = 'a的cmbc银行账户'; commit; # 如果在语句执行期间发生错误，则会回滚该语句。 # 但是如果每个语句都这么写，挺麻烦的。所以在事务里有一个概念叫做自动提交设置！ # 我们每个单语句都会自动提交的，可以自行关闭自动提交！默认是开启的，这个也区别于全局global和会话session
show session variables like 'autocommit'; --查询自动开启提交 show global variables like 'autocommit'; --查询自动开启提交 set session autocommit=0; --关闭自动提交
总结：数据库的事务都是为了解决这种业务场景出现的一门技术，为了保证多个sql语句，要么全部执行成功，要么全部执行失败。
事务的四大特性是什么?
原子性
一个事务必须被视为一个不可分割的最小单元，整个事务中的操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作。
一致性
数据库总是由一个一致性状态转换到另外一个一致性状态。在前面的例子中，一致性确保了，即使在执行第三条第四条预计之间系统崩溃了，cmbc账户中也不会损失10w，要不然a要哭死，如果是系统崩溃最终事务没有提交，所有事务中所作的修改也不会保存到数据库中。
持久性
俗话说就是保证及时落盘；
持久性是为了保证断点等异常的情况，还能保证我们commit的数据不丢失！并且不会回滚！
不会出现我commit之后，重启后又被回滚了！
刚才写了有个undolog能保证原子性，同样的，也有个redolog（重做日志）去保证特殊情况的数据丢失！
redolog会记录每次事务的执行语句！当发生断电等比较不可控的因素后，能根据redolog进行数据恢复！！！
隔离性
一个事务所作的修改在最终提交之前，对其他事务是不可见的。在前面的例子中，我们执行完第三条语句，第四条语句还没成功执行的时候，事务尚未提交。这个时候去看我们acmbc中的账号还有10w，如果这个时候去取钱是不可以的，要等待事务提交了才可以。
刚才我们所看到的，是不是都是一个人或者说是一个线程的问题？
假如我们有很高的并发量，如果有多个事务同时操作同一条数据，会导致什么？
事务因并发出现的问题有哪些？可以查看另一篇文章
链接:
到此这篇关于mysql的事务特性概念梳理总结的文章就介绍到这了,更多相关mysql事务内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！
