数据库事务详解

最新推荐文章于 2024-06-02 14:54:06 发布

天天向上Charles

最新推荐文章于 2024-06-02 14:54:06 发布

阅读量82

点赞数 1

分类专栏： MySQL 文章标签： mysql 数据库后端

本文链接：https://blog.csdn.net/qq_37190972/article/details/131824648

版权

MySQL 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

事务

1. 引子

A用户需要向B用户转账100元，即A用户的账户会少100元，B用户的账户会多100元，对应的SQL语句如下：

update account set balance = balance - 100 where id = 'A';
update account set balance = balance + 100 where id = 'B';

上面的SQL语句并没有使用事务，如果第一条SQL语句执行成功，便会自动提交，此时如果第二条SQL语句执行失败，就会出现A用户账户少了100元，但是B用户的账户并没有多100元的问题。

为了解决上述问题，便需要对上述的SQL语句加上事务，对应的SQL语句如下：

start transaction;
update account set balance = balance - 100 where id = 'A';
update account set balance = balance + 100 where id = 'B';
commit;

这样如果第3条update语句执行失败，整个事务便会回滚，A用户的账户余额会回滚到转账前的样子，只有当两条update语句都执行成功了，才会执行commit提交事务，A用户和B用户的账户余额才会更新到转账后的样子。

2. 事务的四大特性（ACID）

1. 原子性（atomicity）

一个事务就是一个不可分割的最小单元，事务中的所有操作，要么全部执行成功提交，要么执行失败全部回滚，对于一个事务，不可能只执行事务中的某些操作。

2. 一致性（consistency）

数据库是从一个一致性的状态切换到下一个一致性的状态，如果事务没有提交，事务中的所有操作，都不会保存到数据库中。

3. 隔离性（isolation）

一个事务在未提交或回滚之前，对于其他事务来说，是不可见的。在MySQL中，可以设置事务的隔离级别，来自定义事务的隔离性。

4. 永久性（durability）

一旦事务提交，事务中的所有操作，都会保存到数据库中。

3. 事务的隔离级别

1. 读未提交（read uncommitted）

在该隔离级别中，一个事务可以查看其他事务中还没提交的操作，比如上述的转账例子，如果执行到第3条SQL语句时，此时另外一个事务来读取A用户账户余额，会发现余额相对于转账前，是少了100元的，读取未提交的数据，也被称作脏读

2. 读已提交（read committed）

在该隔离级别中，一个事务只能查看其他事务提交或回滚后的数据，大多数的数据库系统的隔离级别都是读已提交，该隔离级别可以解决脏读的问题，但是却会出现不可重复读的问题，例如上述的转账例子，如果存在另外一个事务TransactionB，该事务的执行时间比较长，事务的第一个SQL语句是读取A账户的余额，此时A用户的账户余额是转账前的余额，这时A用户向B用户转账的事务TransactionA执行成功并提交了，后续如果TransactionB再次读取A用户的账户余额，会发现比第一次读取少了100元。同一事务中执行两次相同的SQL语句，会出现不同的结果，这便是不可重复读。

3. 可重复读（repeatable read）

该隔离级别，可以解决上述的不可重复读问题，MySQL事务的默认隔离级别便是可重复读，但是该隔离级别，又会出现一个新的问题，即幻读，所谓幻读，指的是如果一个事务在读取某个范围内的数据时，另一个事务在这个范围内又插入了一些数据，当上一个事务再次读取这个范围内的数据时，会发现比第一次读取的数据要多一些。

4. 可串行化（serializable）

可串行化是最高的事务隔离级别，该级别会强制事务串行执行，事务之间不可能发生冲突。该隔离级别的事务，在读取数据时，也会对数据加上行锁，这样会出现超时或锁等待的问题。实际应用中，很少使用该隔离级别。

总结

隔离级别	脏读	不可重复读	幻读	读加行锁
读未提交（read uncommitted）	Y	Y	Y	N
读已提交（read committed）	N	Y	Y	N
可重复读（repeatable read）	N	N	Y	N
可串行化（serializable）	N	N	N	Y

4. 死锁

当两个及两个以上的事务相互持有对方所需要的资源时，如果这几个事务同时运行，就可能产生死锁。

# 事务A
set transaction;
update account set balance = balance - 100 where id = 'A';
update account set balance = balance + 100 where id = 'B';
commit;

# 事务B
set transaction;
update account set balance = balance + 200 where id = 'B';
update account set balance = balance - 200 where id = 'A';
commit;

如上所示，如果事务A和事务B同时执行，当事务A执行到第3条SQL时，事务B也执行到第3条SQL，此时事务A需要获得id='B’这一行的行锁，但是该锁被事务B所持有，还没有被释放，事务A此时会进入等待状态，同时，事务B也需要id='A’这一行的行锁，但是该行锁此时被事务A所持有，所以事务B也会进入等待状态，这样就产生了死锁，一旦发生死锁，如果不强制回滚其中某个事务，就无法解除死锁。