亲宝软件园·资讯

展开

MySQL事务

向着百万年薪努力的小赵 人气:0

重温事务的概念

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

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

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

假如:

这是事情做成功了,关键点在于,我可不可以反悔。(张三去决定)突出回滚的重要性(原子性)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,如果这个时候去取钱是不可以的,要等待事务提交了才可以。

刚才我们所看到的,是不是都是一个人或者说是一个线程的问题?
假如我们有很高的并发量,如果有多个事务同时操作同一条数据,会导致什么?
事务因并发出现的问题有哪些?可以查看另一篇文章
链接: 

加载全部内容

相关教程
猜你喜欢
用户评论