MySQL事务
2023-04-09 18:23:51 170浏览
1. 什么是数据库事务?
事务,由一个有限的数据库操作序列构成,这些操作要么全部执行,要么全部不执行,是一个不可分割的工作单位。
假如A转账给B 100 元,先从A的账户里扣除 100 元,再在 B 的账户上加上 100 元。如果扣完A的100元后,还没来得及给B加上,银行系统异常了,最后导致A的余额减少了,B的余额却没有增加。所以就需要事务,将A的钱回滚回去,就是这么简单。
2. 事务的四大特性
- 原子性:事务作为一个整体被执行,包含在其中的对数据库的操作要么全部都执行,要么都不执行。
- 一致性:指在事务开始之前和事务结束以后,数据不会被破坏,假如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数据库一般都是集群部署的,会有主库、从库。主库负责写,从库负责读。主库写入之后,会进行主从复制,把数据同步到从库。
从库是在主库拿到bin log日志,并执行bin log,从而保证从库与主库的数据一致性。
实际上,bin log
有三种格式,分别是statement,row和mixed
。如果是statement
格式,bin log
记录的是SQL
的原文。Mysql早些时候,bin log
日志格式只有statement
这种,在RC的隔离级别,可能出现数据不一致的问题。
MySQL官网上还记录了这个bug。
我们可以复现这个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);
执行以下这两个事务:
执行完之后,因为事务的隔离级别是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 Lock
和Next-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),连成一个链表,这个链表就称为版本链。如下:
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 匹配条件规则(很重要)如下:
- 如果数据事务ID
trx_id < min_limit_id
,表明生成该版本的事务在生成Read View前,已经提交(因为事务ID是递增的),所以该版本可以被当前事务访问。 - 如果
trx_id>= max_limit_id
,表明生成该版本的事务在生成Read View后才生成,所以该版本不可以被当前事务访问。 - 如果
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,是怎样的流程
- 获取事务自己的版本号,即
事务ID(trx_id)
- 获取Read View
- 查询得到的数据,然后Read View中的事务版本号进行比较。
- 如果不符合
Read View
的可见性规则, 即就需要Undo log
中历史快照; - 最后返回符合规则的数据
InnoDB 实现MVCC,是通过Read View+ Undo Log
实现的,Undo Log
保存了历史快照,Read View可见性规则帮助判断当前版本的数据是否可见。
9.8 基于MVCC,RC隔离级别,存在不可重复读问题的分析
为了加深大家对MVCC的理解,我们来分析一个例子吧:比如RC隔离级别,存在不可重复读问题,我们来分析这个过程哈。
- 先创建core_user表,插入一条初始化数据,如下:
- 隔离级别设置为读已提交(RC),事务A和事务B同时对core_user表进行查询和修改操作。
事务A: select * fom core_user where id=1
事务B: update core_user set name =”曹操”
最后事务A查询到的结果是,name=曹操的记录,我们基于MVCC,来分析一下执行流程:
(1) A开启事务,首先得到一个事务ID为100 (2) B开启事务,得到事务ID为101 (3) 事务A生成一个Read View,read view对应的值如下
然后回到版本链:开始从版本链中挑选可见的记录:
由图可以看出,最新版本的列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的地址。
(5) 提交事务 (6) 事务A再次执行查询操作,新生成一个Read View,Read View
对应的值如下
然后再次回到版本链:从版本链中挑选可见的记录:
从图可得,最新版本的列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 机制来实现。在高并发的情况下,如果锁的粒度过大或者锁的竞争过激,可能会导致性能瓶颈或者死锁问题,因此需要针对具体场景进行优化。
好博客就要一起分享哦!分享海报
此处可发布评论
评论(0)展开评论
展开评论