【MySQL进阶-04】深入理解mysql事务本质(超级详解)

2023-08-17 116

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云数据库 RDS MySQL，集群系列 2核4GB

RDS MySQL Serverless 基础系列，0.5-2RCU 50GB

云数据库 RDS PostgreSQL，集群系列 2核4GB

简介： 【MySQL进阶-04】深入理解mysql事务本质(超级详解)

一，深入理解mysql事务的隔离级别

1，概述

一般在选择数据库引擎时，都会选择支持事务的innodb这个引擎。在有多个事务的时候，如果存在多个事务同时去操作一张表，就可能会存在并发问题，就会产生脏读，脏写，不可重复读，幻读这些问题。这些事务的本质都是多事务的并发问题，因此在数据库底层设计了多套机制来解决事务并发的问题，如事务的隔离级别，锁机制，mvcc多版本并发控制隔离机制。

2，事务的ACID

原子性(Atomicity)：一个单位的原子操作，要么同时成功，要么同时失败

一致性(Consistent)：在事务开启之后，里面操作数据的状态要一致，要么同时执行，要么同时不执行，不能出现其中一条sql不执行的情况。主要指的是最终的状态

隔离性(Isolation)：通过一定的隔离机制，保证事务不受到外部的影响。

持久性(Durable)：事务完成之后，他对于数据的修改是永久性的，即可以持久化

3，并发事务处理带来的问题

3.1，脏写

即更新丢失，就是指后面的操作覆盖了前面的操作。比如出现并发的问题，两个事务同时操作了一个表的数据，假设一张库存表，事务A和事务B同时获取到了库存的总量为100，然后事务A此时扣减了50个库存，因此库存剩余量是50。但是出现并发情况下，事务B获取的值也是100，那么也是对100这个库存量进行操作，假设事务B要扣20个，那么事务B操作完数据库的值就变成了80，然而实际算上事务A扣除的数据库的值应该是30个，事务A的扣减50个就因为并发问题被事务B的操作给覆盖了，导致了更新丢失的问题。因此这就出现了后面的这个事务将前面的事务操作进行了覆盖的操作，导致出现了脏写的问题。

3.2，脏读

脏读就是读取到了别的事务没有提交的数据。依旧是有一个库存量为100的库存表，此时事务A在做一个减库存的一个更新操作，比如将库存扣减30，那么库存剩余70，并且事务A并未提交；此时有一个查询语句来查询，刚好就查到了事务A还未提交的值70，但是事务A因为异常出现了回滚，那么库存量就又会回到100，那么之前的70就是一个脏数据，而读这个脏数据被称为脏读。那么操作这个脏数据就会出现问题

3.3，不可重复读

就是在一个事务里面先后查询同一个数据值不一样，不符合隔离级别。就比如说上面的库存量为100的表，事务A第一次查这个值是100，然后事务B修改了这个库存值，导致第二次查这个值变成了50，那么就出现了两次读取不一致的问题，即原始读取不可重复，这种现象被称为不可重复读。这种情况不符合隔离性。

3.4，幻读

幻读，顾名思义，就是像出现了幻觉，在一个事务里面再次对一条sql进行查询，突然多了一条数据或者少了一条数据，就像人出现了幻觉一样。即事务A读取到了事务B新增或者删除的数据。也不符合隔离性

二，通过实操来演示mysql的隔离级别以及解决的问题

如下面一张库存表，接下来主要操作这张库存表里面的库存。

CREATE TABLE `stock` (
  `id` bigint(20) NOT NULL,
  `product_id` int(11) DEFAULT NULL COMMENT '商品id',
  `version` int(11) DEFAULT NULL COMMENT '版本',
  `product_count` int(11) DEFAULT NULL COMMENT '商品数量',
  `updated_time` datetime DEFAULT NULL COMMENT '更新时间',
  `created_time` datetime DEFAULT NULL COMMENT '创建时间',
  `is_deleted` tinyint(4) DEFAULT NULL COMMENT '是否删除',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

1，读未提交

设置隔离级别的命令如下，设置当前层级的事务为读未提交

begin;
set session transaction isolation level read uncommitted;

此时右边的事务没有提交，而是出现了回滚，那么此时左边的值读取到的200就是一个脏数据。如果再次查询数据库还好，可以获取到最新的值，但是如果是直接在java代码里面去操作这个获取到的200这个值，那么后面的数据必然会出现问题，如出现少卖的问题等。并且左边的事务在多次查询出现了多个值，因此这种隔离级别也没有解决不可重复读的问题，更没有解决可串行化问题，因为每个串行化都需要加锁，是一个串行操作。

2，读已提交

设置隔离级别的命令如下，设置当前层级的事务为读已提交

set session transaction isolation level read committed;

可以发现读已提交这个隔离级别，在右边的事务修改值而未提交时，左边的事务不能查到右边事务未提交的值。

但是，在右边的事务提交之后，左边的事务查询获取到了右边更新的值。因此这种隔离级别虽然解决了脏读问题，但是并没有解决不可重复度问题，并且事务必须满足acid四大特性，而这个不符合隔离性，读已提交也没有解决串行化的问题。

3，可重复读

设置隔离级别的命令如下，设置当前层级的事务为可重复读

set session transaction isolation level repeatable read;

可重复读这种隔离级别也解决了脏读问题，右边事务更新后未提交，左边的事务也没有获取到这个脏数据。

而右边的事务提交之后，左边的事务再次查询，没有出现这个更改的值。从外观上解决了这个不可重复读问题。因为mysql底层采用了mvcc机制，在更新中会有一个undolog存历史数据，这里展示的就是历史数据，被称为快照读。因此mysql默认使用的是这种事务的隔离级别。

在右边的事务中新插入一条数据，提交之后，左边的事务查询发现数据并没有新增，这里可以发现没有出现幻读问题。

但是，如果左边的事务再次执行一条更新的sql语句，再次查询，发现这个数据又出来了。因此这里就出现了幻读问题，并且也没有满足隔离性。

可重复读就是说：只要当前事务查过一次，不管其他事务是否修改这个值，即使数据库的值真的改变了，当前事务查询的值不会改变，主要是通过这个mvvc机制，来满足这个隔离性。因此在更新时，最好通过操作数据库去实时更新，而不是使用java代码减完之后去更新，这样可以保证最终一致性。

可重复读也没有解决幻读的问题。

4，串行化

设置隔离级别的命令如下，设置当前层级的事务可串行化

set session transaction isolation level serializable;

在前面的三种事务隔离级别中，这个select查询语句是不会加锁的，但是在这个可串行化里面，所有的操作都是会加锁，将所有的并行操作变为串行操作，那这样效率相对较低。由于所有的操作都是串行操作，类似于对sql语句进行了加锁的操作。因此在其中一个事务查询之后，其他的事务就不能去操作被查的那一行数据，直到那个事务提交之后。因此通过这个机制来解决幻读问题。

除了可串行化这个隔离级别可以解决这个幻读问题外，还可以使用这个可重复读这个隔离级别中的间隙锁解决这个问题，和这个串行化的本质都差不多，不过间隙锁相当于一把范围锁，只对这个范围里面的数据进行一个加锁的操作。

由于串行化这个隔离级别的效率太低，mysql最终没有选择这个隔离级别。

三，总结

因此可以通过一张图来总结这个事务的隔离级别问题，同时也通过上面的这几个例子，充分的对以下这张图做一个解释。

因此Mysql默认的事务隔离级别是可重复读，在用Spring开发程序的时候，如果不设置隔离级别，那么默认用Mysql设置的隔离级别，如果Spring设置了就用已经设置的隔离级别。