事务,由一个有限的数据库操作序列构成,这些操作要么全部执行,要么全部不执行,是一个不可分割的工作单位。
假如A转账给B 100 元,先从A的账户里扣除 100 元,再在 B 的账户上加上 100 元。如果扣完A的100元后,还没来得及给B加上,银行系统异常了,最后导致A的余额减少了,B的余额却没有增加。所以就需要事务,将A的钱回滚回去,就是这么简单。
事务的隔离级别有四种,分别是:读未提交(Read Uncommitted)、读已提交(Read Committed)、可重复读(Repeatable Read)、串行化(Serializable)。
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作为隔离级别。
互联网大厂和一些传统企业,最明显的特点就是高并发。那么大厂就更倾向提高系统的并发读。
RC隔离级别,并发度是会比RR更好的,为什么呢?
因为RC隔离级别,加锁过程中,只需要对修改的记录加行锁。而RR隔离级别,还需要加Gap Lock和Next-Key Lock,即RR隔离级别下,出现死锁的概率大很多。并且,RC还支持半一致读,可以大大的减少了更新语句时行锁的冲突;如果对于不满足更新条件的记录,就可以提前释放锁,提升并发度。
一致性读:又称为快照读。快照即当前行数据之前的历史版本。快照读就是使用快照信息显示基于某个时间点的查询结果,而不考虑与此同时运行的其他事务所执行的更改。
当前读: 当前读的规则,就是要能读到所有已经提交的记录的最新值。
半一致性读:一条update语句,如果 where 条件匹配到的记录已经加锁,那么InnoDB会返回记录最近提交的版本,由MySQL上层判断此是否需要真的加锁。
隔离级别脏读不可重复读幻读读未提交(RU)√√√读已提交(RC)×√√可重复读(RR)××√串行化(Serializable)×××
MySQL的隔离级别是通过MVCC和锁机制来实现的。
MVCC,即Multi-Version Concurrency Control(多版本并发控制)。它是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问.
通俗的讲,数据库中同时存在多个版本的数据,并不是整个数据库的多个版本,而是某一条记录的多个版本同时存在,在某个事务对其进行操作的时候,需要查看这一条记录的隐藏列事务版本id,对比事务id并根据事物隔离级别去判断读取哪个版本的数据。
要了解MVCC的底层原理,需要回顾很多相关知识点,我们按以下小提纲,来分析哈:
快照读是MVCC实现的基础。
对于InnoDB存储引擎,每一行记录都有两个隐藏列trx_id、roll_pointer,如果表中没有主键和非NULL唯一键时,则还会有第三个隐藏的主键列row_id。
undo log,回滚日志,用于记录数据被修改前的信息。在表记录修改之前,会先把数据拷贝到undo log里,如果事务回滚,即可以通过undo log来还原数据。
可以这样认为,当delete一条记录时,undo log中会记录一条对应的insert记录,当update一条记录时,它记录一条对应相反的update记录。
undo log有什么用途呢?
多个事务并行操作某一行数据时,不同事务对该行数据的修改会产生多个版本,然后通过回滚指针(roll_pointer),连成一个链表,这个链表就称为版本链。如下:
事务每次开启前,都会从数据库获得一个自增长的事务ID,可以从事务ID(trx_id)判断事务的执行先后顺序。这就是事务版本号。
Read View是什么呢?它就是事务执行SQL语句时,产生的读视图。实际上在innodb中,每个SQL语句执行前都会得到一个Read View。它主要是用来做可见性判断的,即判断当前事务可见哪个版本的数据~
在Read View中,有这几个重要的属性。
Read view 匹配条件规则(很重要)如下:
(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生成之前就已经提交了,修改的结果,当前事务是能看见的。
InnoDB 实现MVCC,是通过Read View+ Undo Log实现的,Undo Log保存了历史快照,Read View可见性规则帮助判断当前版本的数据是否可见。
为了加深大家对MVCC的理解,我们来分析一个例子吧:比如RC隔离级别,存在不可重复读问题,我们来分析这个过程哈。
事务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的这个记录,当前事务是可见的。所以查到是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这个记录,对于当前事务是可见的。所以SQL查询到的是name为曹操的记录。
综上所述,在读已提交(RC)隔离级别下,同一个事务里,两个相同的查询,读取同一条记录(id=1),却返回了不同的数据(第一次查出来是孙权,第二次查出来是曹操那条记录),因此RC隔离级别,存在不可重复读并发问题。
而在RR隔离级别,一个事务里,每一次查询,都只会获取一次read view,都是副本共用的,从而保证每次查询的数据都是一样的,因此它是解决了不可重复读的并发问题的哈。大家可以自己手动去分析以下,这就是MVCC原理所在,也可以看我之前写的这篇文章哈,写得很清晰:看一遍就理解,MVCC原理详解
处理大事务和长事务是数据库设计和优化中非常重要的一部分,以下是一些常用的处理方法:
MySQL 事务性能优化是提高数据库性能的关键之一,以下是一些常用的优化方法:
当然,这些方法可能并不适用于所有业务场景,需要根据具体情况进行选择和调整。
InnoDB 是 MySQL 中一种常用的存储引擎,支持事务和行级锁等高级特性。以下是 InnoDB 实现事务的基本原理:
来源:https://mp.weixin.qq.com/s/KEbuoasD_DOHRJiSqUgzzA
页面更新:2024-05-23
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号