重温事务的概念
为什么用事务、事务是什么
我们规定了，做一件事情，只有成功和失败!
用个很经典的例子举例：
银行转账，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事务内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
