[大数据]MySQL的事务概念

重温事务的概念

为什么用事务、事务是什么

我们规定了，做一件事情，只有成功和失败!
用个很经典的例子举例：
银行转账，A向B转账十万，能不能发生一遍付钱一边没收钱的情况？
现实中一定是A和B同时成功或者失败，不能出现一边成功另一边失败的情景，这就是事务的简单例子。

那么由这个例子我们想想事务其实是为了保证什么？
假如：

1. 张三问罗老师借钱，借了钱没写借据。
   这是做了事情，但是没有依据，就算做成功了，也没办法证明。突出借据的重要性（持久性） redolog
2. 张三问罗老师借钱，罗老师同意了，可是张三不想借了。
   这是事情做成功了，关键点在于，我可不可以反悔。（张三去决定）突出回滚的重要性（原子性）undo log

所以**事务其实就是想要做的事情是一个整体！**事务的存在目的就是为了事情能够正确成功的执行。

如果以数据库的角度去看：
在关系型数据库中，事务其实就是【一组原子性的SQL】或者说一个独立不可分割的工作单元，如果数据库引擎能成功的对数据库引用该组查询的全部语句，那么就执行该组查询，如果其中有任何一条语句因为崩溃或者其他原因无法执行，那么所有的语句都不会执行，也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。

那么刚才那个转账的例子，让我们去写一个事务，应该怎么写？

1. 查询A账户的余额是否大于10W块钱
2. 从A账户余额中减去10W块钱
3. 在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脏读幻读不可重复读及事务的隔离级别和MVCC实现