MySQL事务

时间:2023-04-05 20:05:41

MySQL事务

1. 什么是数据库事务?

事务,由一个有限的数据库操作序列构成,这些操作要么全部执行,要么全部不执行,是一个不可分割的工作单位。

假如A转账给B 100 元,先从A的账户里扣除 100 元,再在 B 的账户上加上 100 元。如果扣完A的100元后,还没来得及给B加上,银行系统异常了,最后导致A的余额减少了,B的余额却没有增加。所以就需要事务,将A的钱回滚回去,就是这么简单。

2. 事务的四大特性

MySQL事务

  • 原子性:事务作为一个整体被执行,包含在其中的对数据库的操作要么全部都执行,要么都不执行。
  • 一致性:指在事务开始之前和事务结束以后,数据不会被破坏,假如A账户给B账户转10块钱,不管成功与否,A和B的总金额是不变的。
  • 隔离性:多个事务并发访问时,事务之间是相互隔离的,一个事务不应该被其他事务干扰,多个并发事务之间要相互隔离。
  • 持久性:表示事务完成提交后,该事务对数据库所作的操作更改,将持久地保存在数据库之中。

3. 事务的隔离级别有哪些?MySQL的默认隔离级别是什么?

事务的隔离级别有四种,分别是:读未提交(Read Uncommitted)、读已提交(Read Committed)、可重复读(Repeatable Read)、串行化(Serializable)。

  • 读未提交隔离级别:只限制了两个数据不能同时修改,但是修改数据的时候,即使事务未提交,都是可以被别的事务读取到的,这级别的事务隔离有脏读、重复读、幻读的问题;
  • 读已提交隔离级别:当前事务只能读取到其他事务提交的数据,所以这种事务的隔离级别解决了脏读问题,但还是会存在重复读、幻读问题;
  • 可重复读: 可重复读隔离级别,限制了读取数据的时候,不可以进行修改,所以解决了重复读的问题,但是读取范围数据的时候,是可以插入数据,所以还会存在幻读问题;
  • 串行化: 事务最高的隔离级别,在该级别下,所有事务都是进行串行化顺序执行的。可以避免脏读、不可重复读与幻读所有并发问题。但是这种事务隔离级别下,事务执行很耗性能。

Mysql默认的事务隔离级别是可重复读(RR)。

4. Mysql为什么选择RR作为默认隔离级别?

我们知道Mysql有四种数据库隔离级别,分别是读未提交、读已提交、可重复读、串行化。而读未提交隔离级别太低了,会有脏读问题,串行化隔离级别太高了,会影响并发读。那么就剩下读已提交(RC)和可重复读(RR)了。

那么,Mysql为什么会选择RR作为默认隔离级别呢?

我们的MySQL数据库一般都是集群部署的,会有主库、从库。主库负责写,从库负责读。主库写入之后,会进行主从复制,把数据同步到从库。

MySQL事务

从库是在主库拿到bin log日志,并执行bin log,从而保证从库与主库的数据一致性。

实际上,bin log有三种格式,分别是statement,row和mixed。如果是statement格式,bin log记录的是SQL原文。Mysql早些时候,bin log日志格式只有statement这种,在RC的隔离级别,可能出现数据不一致的问题。

MySQL官网上还记录了这个bug。

MySQL事务

我们可以复现这个bug,假设有表结构如下:

CREATE TABLE t (
      a int(11) DEFAULT NULL,
      b int(11) DEFAULT NULL,
      KEY a (a)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

插入两条数据

insert into t values(666,2),(233,1);

执行以下这两个事务:

MySQL事务

执行完之后,因为事务的隔离级别是RC,所以事务A在更新时,会对 b=2加行级锁,所以执行结果为(888,2),事务B在执行时,不受行级锁的影响,两条数据变为(888,2),(233,2)

在RC隔离级别下,我们再来看下bin log日志。当两个事务执行完后,会先记录事务B的bin log日志,因为它最先提交,然后才生成事务A的bin log日志。当bin log日志格式是statement,binlog记录的就是原文,也就是先记录update t set b=2 where b = 1;,然后才记录update t set a=888 where b=2

酱紫的话,当主库把binlog同步到从库,执行SQL回放后,数据库中的数据就变成了(888,2)和(888,2),主数据库和从数据库数据不一致啦。而在RR(可重复读的数据库隔离级别)下,因为会有间隙锁的存在,这种情况就不会发生,因此,Mysql默认选择RR作为隔离级别。

5. 很多大厂为什么选择RC数据库隔离级别?

互联网大厂和一些传统企业,最明显的特点就是高并发。那么大厂就更倾向提高系统的并发读

RC隔离级别,并发度是会比RR更好的,为什么呢?

因为RC隔离级别,加锁过程中,只需要对修改的记录加行锁。而RR隔离级别,还需要加Gap LockNext-Key Lock,即RR隔离级别下,出现死锁的概率大很多。并且,RC还支持半一致读,可以大大的减少了更新语句时行锁的冲突;如果对于不满足更新条件的记录,就可以提前释放锁,提升并发度。

  • 一致性读:又称为快照读。快照即当前行数据之前的历史版本。快照读就是使用快照信息显示基于某个时间点的查询结果,而不考虑与此同时运行的其他事务所执行的更改。
  • 当前读: 当前读的规则,就是要能读到所有已经提交的记录的最新值。
  • 半一致性读:一条update语句,如果 where 条件匹配到的记录已经加锁,那么InnoDB会返回记录最近提交的版本,由MySQL上层判断此是否需要真的加锁。

6.  并发场景,数据库存在哪些一致性问题?

  • 脏读:如果一个事务读取到了另一个未提交事务修改过的数据,我们就称发生了脏读现象。
  • 不可重复读:同一个事务内,前后多次读取,读取到的数据内容不一致
  • 幻读:如果一个事务先根据某些搜索条件查询出一些记录,在该事务未提交时,另一个事务写入了一些符合那些搜索条件的记录(如insert、delete、update),就意味着发生了幻读。
  • 丢失更新:事务A和事务B都对同一个数据进行修改,事务A先修改,事务B随后修改,事务B的修改覆盖了事务A的修改。

7. 四大隔离级别,都会存在哪些并发问题呢?

隔离级别

脏读

不可重复读

幻读

读未提交(RU)




读已提交(RC)

×



可重复读(RR)

×

×


串行化(Serializable)

×

×

×

  • 在RU隔离级别下,可能发生脏读、不可重复读、幻读现象。
  • 在RC隔离级别下,可能发生不可重复读、幻读现象。
  • 在RR隔离级别下,可能发生幻读现象。
  • 在Serializable隔离级别,会强制事务串行执行,不会存在脏读、不可重复读、幻读现象。

8. MySQL的隔离级别是如何实现的?

MySQL的隔离级别是通过MVCC和锁机制来实现的。

  • RU隔离级别最低,没有加锁,存在脏读问题。事务读不加锁,不阻塞其他事务的读和写
  • RC和RR隔离级别可以通过MVCC来实现。
  • 串行化是通过锁机制实现。读加共享锁,写加排他锁,读写互斥。如果有未提交的事务正在修改某些行,所有select这些行的语句都会阻塞。

9. 什么是MVCC,它的底层原理?

MVCC,即Multi-Version Concurrency Control(多版本并发控制)。它是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问.

通俗的讲,数据库中同时存在多个版本的数据,并不是整个数据库的多个版本,而是某一条记录的多个版本同时存在,在某个事务对其进行操作的时候,需要查看这一条记录的隐藏列事务版本id,对比事务id并根据事物隔离级别去判断读取哪个版本的数据。

要了解MVCC的底层原理,需要回顾很多相关知识点,我们按以下小提纲,来分析哈:

  • 什么是快照读和当前读
  • 隐式字段
  • 什么是Undo Log
  • 什么是快照版本链
  • 事务版本号
  • 什么是Read View
  • 查询一条记录,基于MVCC,是怎样流程
  • 基于MVCC,RC隔离级别,存在不可重复读问题的分析

9.1 什么是快照读和当前读

  • 快照读:读取的是记录数据的可见版本(有旧的版本)。不加锁,普通的select语句都是快照读。
  • 当前读:读取的是记录数据的最新版本,显式加锁的都是当前读。

快照读是MVCC实现的基础。

9.2 隐式字段

对于InnoDB存储引擎,每一行记录都有两个隐藏列trx_id、roll_pointer,如果表中没有主键和非NULL唯一键时,则还会有第三个隐藏的主键列row_id

9.3 什么是Undo Log

undo log,回滚日志,用于记录数据被修改前的信息。在表记录修改之前,会先把数据拷贝到undo log里,如果事务回滚,即可以通过undo log来还原数据。

可以这样认为,当delete一条记录时,undo log中会记录一条对应的insert记录,当update一条记录时,它记录一条对应相反的update记录。

undo log有什么用途呢?

  • 事务回滚时,保证原子性和一致性。
  • 用于MVCC快照读。

9.4 快照版本链

多个事务并行操作某一行数据时,不同事务对该行数据的修改会产生多个版本,然后通过回滚指针(roll_pointer),连成一个链表,这个链表就称为版本链。如下:

MySQL事务

9.5 事务版本号

事务每次开启前,都会从数据库获得一个自增长的事务ID,可以从事务ID(trx_id)判断事务的执行先后顺序。这就是事务版本号。

9.6 什么是Read View

Read View是什么呢?它就是事务执行SQL语句时,产生的读视图。实际上在innodb中,每个SQL语句执行前都会得到一个Read View。它主要是用来做可见性判断的,即判断当前事务可见哪个版本的数据~

Read View中,有这几个重要的属性。

  • m_ids:当前系统中,那些未提交的读写事务ID列表。
  • min_limit_id:表示在生成Read View时,当前系统中活跃的读写事务中最小的事务id,即m_ids中的最小值。
  • max_limit_id:表示生成Read View时,系统中应该分配给下一个事务的id值。
  • creator_trx_id: 创建当前Read View的事务ID

Read view 匹配条件规则(很重要)如下:

  1. 如果数据事务ID trx_id < min_limit_id,表明生成该版本的事务在生成Read View前,已经提交(因为事务ID是递增的),所以该版本可以被当前事务访问。
  2. 如果trx_id>= max_limit_id,表明生成该版本的事务在生成Read View后才生成,所以该版本不可以被当前事务访问。
  3. 如果 min_limit_id =<trx_id< max_limit_id,需腰分3种情况讨论
  • (1).如果m_ids包含trx_id,则代表Read View生成时刻,这个事务还未提交,但是如果数据的trx_id等于creator_trx_id的话,表明数据是自己生成的,因此是可见的。
  • (2)如果m_ids包含trx_id,并且trx_id不等于creator_trx_id,则Read   View生成时,事务未提交,并且不是自己生产的,所以当前事务也是看不见的;
  • (3).如果m_ids不包含trx_id,则说明你这个事务在Read View生成之前就已经提交了,修改的结果,当前事务是能看见的。

9.7 查询一条记录,基于MVCC,是怎样的流程

  1. 获取事务自己的版本号,即事务ID(trx_id)
  2. 获取Read View
  3. 查询得到的数据,然后Read View中的事务版本号进行比较。
  4. 如果不符合Read View的可见性规则, 即就需要Undo log中历史快照;
  5. 最后返回符合规则的数据

InnoDB 实现MVCC,是通过Read View+ Undo Log实现的,Undo Log保存了历史快照,Read View可见性规则帮助判断当前版本的数据是否可见。

9.8 基于MVCC,RC隔离级别,存在不可重复读问题的分析

为了加深大家对MVCC的理解,我们来分析一个例子吧:比如RC隔离级别,存在不可重复读问题,我们来分析这个过程哈。

  1. 先创建core_user表,插入一条初始化数据,如下:

MySQL事务

  1. 隔离级别设置为读已提交(RC),事务A和事务B同时对core_user表进行查询和修改操作。
事务A: select * fom core_user where id=1
事务B: update core_user set name =”曹操”

MySQL事务

最后事务A查询到的结果是,name=曹操的记录,我们基于MVCC,来分析一下执行流程:

(1) A开启事务,首先得到一个事务ID为100 (2) B开启事务,得到事务ID为101 (3) 事务A生成一个Read View,read view对应的值如下

MySQL事务

然后回到版本链:开始从版本链中挑选可见的记录:

MySQL事务

由图可以看出,最新版本的列name的内容是孙权,该版本的trx_id值为100。判断read view可见性规则校验:

min_limit_id(100)=<trx_id(100)<102;
creator_trx_id = trx_id =100;

由此可得,trx_id=100的这个记录,当前事务是可见的。所以查到是name为孙权的记录。

(4) 事务B进行修改操作,把名字改为曹操。把原数据拷贝到undo log,然后对数据进行修改,标记事务ID和上一个数据版本在undo log的地址。

MySQL事务

(5) 提交事务 (6) 事务A再次执行查询操作,新生成一个Read ViewRead View对应的值如下

MySQL事务

然后再次回到版本链:从版本链中挑选可见的记录:

MySQL事务

从图可得,最新版本的列name的内容是曹操,该版本的trx_id值为101。判断Read View可见性规则校验:

min_limit_id(100)=<trx_id(101)<max_limit_id(102);
但是,trx_id=101,不属于m_ids集合

因此,trx_id=101这个记录,对于当前事务是可见的。所以SQL查询到的是name为曹操的记录。

综上所述,在读已提交(RC)隔离级别下,同一个事务里,两个相同的查询,读取同一条记录(id=1),却返回了不同的数据(第一次查出来是孙权,第二次查出来是曹操那条记录),因此RC隔离级别,存在不可重复读并发问题。

而在RR隔离级别,一个事务里,每一次查询,都只会获取一次read view,都是副本共用的,从而保证每次查询的数据都是一样的,因此它是解决了不可重复读的并发问题的哈。大家可以自己手动去分析以下,这就是MVCC原理所在,也可以看我之前写的这篇文章哈,写得很清晰:看一遍就理解,MVCC原理详解

10. 如何处理大事务和长事务?请给出一些处理方法。

处理大事务和长事务是数据库设计和优化中非常重要的一部分,以下是一些常用的处理方法:

  • 大事务拆分为小事务:将大事务拆分为多个小事务,减少每个事务操作的数据量,可以减少锁竞争和死锁的风险,提高并发性能。
  • 优化查询语句:对于长事务中的查询操作,可以通过优化查询语句来提高查询性能,如添加索引、优化SQL结构等。
  • 避免长时间占用锁:长事务会占用锁资源,导致其他事务无法访问相应的数据,因此需要尽可能缩短事务的执行时间,避免长时间占用锁。
  • 避免长时间的事务等待:长事务可能会导致其他事务的等待时间过长,影响系统的性能和可用性,因此需要尽可能缩短事务的执行时间,避免长时间的事务等待。
  • 优化事务日志:长事务会占用大量的事务日志,导致数据库性能下降,因此需要通过优化事务日志的写入和刷盘策略来提高性能。
  • 使用定时任务:长时间运行的事务可以通过定时任务来定期执行,以避免长时间占用资源。
  • 适当增加硬件资源:如果以上方法不能解决问题,可以适当增加硬件资源,如增加内存、CPU、存储等,以提高系统性能。

11. 如何优化 MySQL 事务的性能?请列举一些优化方法。

MySQL 事务性能优化是提高数据库性能的关键之一,以下是一些常用的优化方法:

  • 选择合适的存储引擎:不同的存储引擎具有不同的特性和性能,因此需要根据具体的业务需求选择合适的存储引擎,如 MyISAM、InnoDB、Memory 等。
  • 使用合适的索引:合理的索引可以提高查询和更新操作的效率,因此需要根据实际业务情况添加适当的索引,避免全表扫描。
  • 避免不必要的锁定:不必要的锁定会降低并发性能,因此需要避免不必要的锁定,如优化查询语句、使用乐观锁等。
  • 选择合适的事务隔离级别:不同的事务隔离级别具有不同的特性和性能影响,因此需要根据实际业务情况选择合适的事务隔离级别。
  • 减少事务的范围:尽量减小事务的范围,将大事务拆分为多个小事务,可以减少锁竞争和死锁的风险,提高并发性能。
  • 使用合适的事务提交方式:对于不需要回滚的事务,可以使用自动提交方式,减少提交操作的次数,提高性能。
  • 避免长事务:长时间运行的事务会占用大量的资源,影响并发性能,因此需要尽可能缩短事务的执行时间,避免长时间的事务等待。
  • 化数据库服务器的硬件和配置:优化数据库服务器的硬件和配置可以提高数据库性能,如增加内存、优化磁盘性能、调整缓存大小等。
  • 使用分布式数据库:对于高并发的场景,可以使用分布式数据库架构,将数据分布到多个数据库节点上,提高并发性能。

当然,这些方法可能并不适用于所有业务场景,需要根据具体情况进行选择和调整。

12. Innodb的事务实现的基本原理

InnoDB 是 MySQL 中一种常用的存储引擎,支持事务和行级锁等高级特性。以下是 InnoDB 实现事务的基本原理:

  • InnoDB 中,每个事务都拥有一个唯一的事务 ID(transaction ID),通过该 ID 来区分不同的事务。
  • InnoDB 使用 MVCC(多版本并发控制)来实现事务的隔离性,每次修改会生成一个新版本,查询时只能看到在查询开始之前就已经提交的版本,这样可以避免读取到脏数据。
  • 在执行事务中的更新操作时,InnoDB 会根据需要对相关的数据行加锁,以保证事务的原子性和一致性。InnoDB 中的行级锁是通过在索引节点上加锁来实现的,因此对于相同的数据行,不同的事务可以分别通过不同的索引来访问和修改数据。
  • InnoDB 中的事务支持 ACID 特性,即原子性、一致性、隔离性和持久性。InnoDB 通过 redo log 和 undo log 来保证事务的原子性和持久性,其中 redo log 记录了事务的修改操作,而 undo log 则记录了事务的回滚操作。当系统崩溃或者发生其他故障时,InnoDB 可以通过 redo log 和 undo log 来恢复数据到事务提交前的状态,以保证数据的一致性和持久性。
  • InnoDB 中的事务隔离级别包括读未提交、读已提交、可重复读和串行化。默认的隔离级别是可重复读,使用锁和 MVCC 机制来实现。在高并发的情况下,如果锁的粒度过大或者锁的竞争过激,可能会导致性能瓶颈或者死锁问题,因此需要针对具体场景进行优化。