深入解析MySQL的事务隔离及其对性能产生的影响_Mysql

 SQL标准定义了4类隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的。低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销。
Read Uncommitted(读取未提交内容)
       在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少。读取未提交的数据,也被称之为脏读(Dirty Read)。
Read Committed(读取提交内容)
       这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。它满足了隔离的简单定义:一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读(Nonrepeatable Read),因为同一事务的其他实例在该实例处理其间可能会有新的commit,所以同一select可能返回不同结果。
Repeatable Read(可重读)
       这是MySQL的默认事务隔离级别,它确保同一事务的多个实例在并发读取数据时,会看到同样的数据行。不过理论上,这会导致另一个棘手的问题:幻读 (Phantom Read)。简单的说,幻读指当用户读取某一范围的数据行时,另一个事务又在该范围内插入了新行,当用户再读取该范围的数据行时,会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制(MVCC,Multiversion Concurrency Control)机制解决了该问题。
Serializable(可串行化) 
       这是最高的隔离级别,它通过强制事务排序,使之不可能相互冲突,从而解决幻读问题。简言之,它是在每个读的数据行上加上共享锁。在这个级别,可能导致大量的超时现象和锁竞争。
         这四种隔离级别采取不同的锁类型来实现,若读取的是同一个数据的话,就容易发生问题。例如:

  •          脏读(Drity Read):某个事务已更新一份数据,另一个事务在此时读取了同一份数据,由于某些原因,前一个RollBack了操作,则后一个事务所读取的数据就会是不正确的。
  •          不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致,这可能是两次查询过程中间插入了一个事务更新的原有的数据。
  •          幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致,例如有一个事务查询了几列(Row)数据,而另一个事务却在此时插入了新的几列数据,先前的事务在接下来的查询中,就会发现有几列数据是它先前所没有的。

         在MySQL中,实现了这四种隔离级别,分别有可能产生问题如下所示:


MySQL事务隔离级别对其性能的影响
MySQL默认工作在级别三下。我们知道事务隔离是为了避免并发操作相互影响而导数据的不一致性。所以为了保证数据的一致性,就引入了事务隔离的功能。以上四个级别的对数据的一致性保护是逐步提高的。级别4对事务的隔离效果最好,但是性能最差,一般不再生产环境中使用。
下面通过实例来检验不同级别下MySQL性能收到的影响。我的实验环境是:Redhat5.8+MySQL5.5
首先我们这里启用两个session:
1、验证级别一的特性
我们在session A上进行的操作为:

在session B上的操作同session A,这里不再附上截图。
       接下来我们就通过一系列的实验来观察READ-UNCOMMITTED到底是什么,它到底有什么特性,对我们的操作到底有什么影响。首先,我们可以看到表中的初始数据如下:

接下来我们在sessionA上更改其中的一条记录,更改结果如下:

注意:我们在上面启用了事务,但是我们在这里并没有进行commit操作。
 
接下来我们在sessionB中对刚才改过的表进行select查询,查询结果如下:

我们可以清楚的看到,虽然我们并没有对session A的结果进行commit,但是结果确实已经改变。因此在这种级别下,没有提交的操作会对数据的一致性有影响。因此,如果我们此时在session A上对上述操作进行回滚,我们会发现此时session B上的结果又回到原来最初的结果,这样就造成了数据的不一致性,这也称为数据的幻读现象,看起来是很诡异的事情。因此在某些场景下,我们应该避免这种现象的产生。但是这种级别也不是没有它的用武之地,比如当我们有大量数据需要写入,而读操作很少的时候,就适合用这种模式。
可以看到session A回滚后,session B中的数据又变成最初的样子,这也称为幻读:

2、验证级别READ COMMITTED特性
       首先把session A和session B的隔离级别都改为READ-COMMITTED,并且全部都开启事务,操作如下:

接下来我们查看tutors表的初始状态信息:

然后我们依然是对数据进行更新操作,更新之后仍然没有commit。我们可以看到在sessionA中,结果已经发生改变:

此时我们在session B中查看,发现结果依然维持不变:

但是,如果我们此时在session A中进行commit操作,我们就会发现,sessionB此时查询就会发生改变,这样也造成了数据的前后不一致性,也是数据的幻读:

3、数据的可重读
       数据的可重读,也叫作REPEATABLE-READ,这是MySQL默认采用的事务隔离级别,有其优势,但是仍然没有从根本上解决数据的一致性问题。首先,还是让我们来测试一下,在这种级别下MySQL到底是如何工作的,又有哪些特性,我们又该怎样去操作。
       我们先把REPEATABLE-READ的环境设置好,具体的操作方法如下:

然后我们在查看其初始数据,其结果如下:

我们在session A中修改数据,并进行commit,修改后的结果如下:

然后我们在session B中进行查看发现结果仍然没有任何改变:

这就是可重读的特性,只要本次会话不提交,尽管对方修改,但是结果仍然不变,只有在session B中也进行commit操作,所作的修改才会在sessionB中生效。
 
4、seriabliable
这个级别是事务隔离安全性最好的,但是也是性能最差的,因为这个级别所有的操作都是串行进行的。一个操作没有提交,另一个受到影响的操作会处于阻塞状态。
为了验证这种效果,我们先把环境设置好,具体为在session A和session B同时设置如下:

在session A 中对其任意字段进行修改,并且没有进行commit操作。此时挥发现sessionB中的查询操作会一直处于阻塞状态:

这就设串行化隔离的效果,也是为什么串行化隔离并发能力差的原因。

时间: 2024-10-29 14:03:35

深入解析MySQL的事务隔离及其对性能产生的影响_Mysql的相关文章

MySQL的事务隔离级别和锁

MySQL的事务隔离级别:Read Uncommitted[读未提交数据]Read Committed[读已提交数据]Repeatable Read[可重读]Serializable[可串行化] 查看MySQL的事务隔离级别:默认.全局和会话事务隔离级别: SELECT @@tx_isolation SELECT @@global.tx_isolation; SELECT @@session.tx_isolation; mysql> select @@tx_isolation; +-------

MySQL数据库事务隔离级别介绍(Transaction Isolation Level)_Mysql

数据库隔离级别有四种,应用<高性能mysql>一书中的说明: 然后说说修改事务隔离级别的方法: 1.全局修改,修改mysql.ini配置文件,在最后加上 复制代码 代码如下:  #可选参数有:READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE. [mysqld] transaction-isolation = REPEATABLE-READ 这里全局默认是REPEATABLE-READ,其实MySQL本来默认也是这个级

mysql的事务隔离

三个并发问题 1.脏读 读取未提交的数据,也叫脏读(Dirty read) 两个(多个)事物,前一个事物修改了数据,但是没提交,另一个事物来读取这些数据,这时候前面那个事物RollBack了,这时候后面的事物读取的数据就是错的. 简单理解 在一事务中读取到其他未提交事务的数据 2.不可重复读 一个事务两次读取的数据内容不一致. 两个(多个)事物,前面一个事物读取了数据,第二个事物修改了这些数据,前面这个事物再去读这些数据,出现前后两次读取的数据不一样. 简单理解在一事务中读取到其他已提交事务的数

mysql+Spring数据库隔离级别与性能分析_Mysql

这里以mysql为例,先明确以下几个问题: 一.一般项目如果不自己配置事务的话,一般默认的是autocommit,即执行完一个操作后自动commit,提交事务. (注:事务是绑定在数据库操作上的,也就是当程序执行(statement.excute等操作)转而到数据库层面上的时候,事务才开始发生)当然spring可以将几个数据库操作动作绑在一个事务中,这样就需要介绍下spring事务配置方法,下面介绍的是常用方法,其他方法网上有很多.spring提供了很多事务配置的策略,很方便,简要介绍一下: 复

浅谈InnoDB隔离模式的使用对MySQL性能造成的影响_Mysql

在这篇文章里我将讨论一个相关的主题 – InnoDB 事务隔离模式,还有它们与MVCC(多版本并发控制)的关系,以及它们是如何影响MySQL性能的. MySQL手册提供了一个关于MySQL支持的事务隔离模式的恰当描述 – 在这里我并不会再重复,而是聚焦到对性能的影响上. SERIALIZABLE – 这是最强的隔离模式,本质上打败了在锁管理(设置锁是很昂贵的)的条件下,多版本控制对所有选择进行锁定造成大量的开销,还有你得到的并发.这个模式仅在MySQL应用中非常特殊的情况下使用. REPEATA

php+mysql prepare 与普通查询的性能对比实例讲解_Mysql

php+mysql prepare 与普通查询的性能对比 实例代码如下: <?php class timer { public $StartTime = 0; public $StopTime = 0; public $TimeSpent = 0; function start(){ $this->StartTime = microtime(); } function stop(){ $this->StopTime = microtime(); } function spent() {

解析Mysql备份与恢复简单总结与tee命令的使用介绍_Mysql

备份数据方法:一:sql语句.LOCKS TABLES tablename READ;//读锁定尝试锁定表之前,LOCK TABLES不是事务安全型的,会隐含地提交所有活性事务,同时,会隐含地开始一项事务(例如,使用START TRANSACTION),所以,对事务表(如InnoDB)使用LOCK TABLES的正确方法是,设置AUTOCOMMIT=0FLUSH TABLES,SELECT * INTO OUTFILE 'data_bck.sql' FIELDS TERMINATED BY ',

解析mysql修改为utf8后仍然有乱码的问题_Mysql

解决方法:1.找到mysql安装目录c:\Program Files\MySQL\MySQL Server 5.5下的my.ini2.修改一下三处,注意通常只能搜索到[mysql]和[mysqld]两处,[client]处需要增加:[client]default-character-set=utf8[mysql]default-character-set=utf8[mysqld]default-character-set=utf83.保存my.ini,在控制面板里找到服务,重启mysql服务.

深入解析mysql中order by与group by的顺序问题_Mysql

mysql 中order by 与group by的顺序是:selectfromwheregroup byorder by注意:group by 比order by先执行,order by不会对group by 内部进行排序,如果group by后只有一条记录,那么order by 将无效.要查出group by中最大的或最小的某一字段使用 max或min函数.例:select sum(click_num) as totalnum,max(update_time) as update_time,