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

这里以mysql为例，先明确以下几个问题：

一.一般项目如果不自己配置事务的话，一般默认的是autocommit，即执行完一个操作后自动commit，提交事务。

（注：事务是绑定在数据库操作上的，也就是当程序执行（statement.excute等操作）转而到数据库层面上的时候，事务才开始发生）
当然spring可以将几个数据库操作动作绑在一个事务中，这样就需要介绍下spring事务配置方法，下面介绍的是常用方法，其他方法网上有很多。
spring提供了很多事务配置的策略，很方便，简要介绍一下：

代码如下:

<property name="transactionAttributes">
<props>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
</props>

一般spring配置事务都是以上的配法，具体参数的意思有不懂的上网自己查吧，那么需要注意以下几点：（题外话）
1.我习惯将事务配置在service上，这时需要注意，只有service中以save、update等开头的方法，配置的事务才有效果。如果service中的方法名不是以save等开头的，比如taskSave()方法，即使在实现类中调用了service中的update方法，配置事务也失效，我试过。
2.readOnly这个属性很有意思，因为用了它后，会自动将数据库的隔离级别提高了一级，由提交读变为重复读，这块我后面说明。

二.数据库隔离级别

数据库隔离级别主要有以下四个：不可提交读，提交读，重复读和序列化读（以下理解可以不看）。
1. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。
     这种隔离级别会产生脏读，不可重复读和幻像读。
2. ISOLATION_READ_COMMITTED： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据
3. ISOLATION_REPEATABLE_READ： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
     它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
4. ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。
     除了防止脏读，不可重复读外，还避免了幻像读。
mysql默认的隔离级别是重复读，即 ISOLATION_REPEATABLE_READ。

注意：其中未提交读与序列化读不常用，未提交读危险性太高，会读到很多脏数据。而可串行化读是通过将读取的每一行数据加锁，以耗费性能为代价换取的，所以使用也很少，大部分数据库的隔离级别是提交读，比如oracle、sqlserver。而mysql默认的数据隔离级别是可重复读。

下面我来结合项目分析以下调整数据库隔离级别对性能的影响：
本地mysql数据库由ISOLATION_REPEATABLE_READ级别降低到ISOLATION_READ_COMMITTED级别：

场景：未用Spring，用户A在一个事务中对数据库发出两次查询请求，在两次查询之间，用户B对数据库的记录进行修改。

结果：ISOLATION_REPEATABLE_READ级别：用户A两次查询结果不一样。

ISOLATION_READ_COMMITTED级别：用户A两次查询结果一样，因为对记录进行了加锁操作。

以task模块为例，在本地运行任务首页，通过对比分析两种事务处理方式得到如下结果(每次统计数据前均清理浏览器缓存，统计3次取平均值)：


发现降低数据库事务的隔离级别，对于一些特殊逻辑的操作上，性能有所提升。
但是如果查询过程中，不涉及同一事务中多次对数据库操作的复杂逻辑及同一事务中多次查询同一结果集的逻辑，则对速度的提升效果并不明显，即事务进行时对数据集加锁的时间是可以忽略的，下面再来理解一下事务隔离级别与锁的关系。

谈到数据库隔离级别，就要说一下锁的概念：

主要分为共享锁和排他锁。
共享锁：由读表操作加上的锁，加锁后其他用户只能获取该表或行的共享锁，不能获取排它锁，也就是说只能读不能写

排它锁：由写表操作加上的锁，加锁后其他用户不能获取该表或行的任何锁，典型是mysql事务中。

个人理解：共享锁和排他锁没有严格的界限，我认为应该通过结果确定加的是共享锁还是排他锁。

例如：用户A修改一条数据，用户B也修改这条数据，挂起。 但是B查看这个数据可以，证明A用户添加了行级共享锁。

再例如：用户A修改一条数据，用户B查询这条数据失败，查询其他数据也失败。那么肯定A加了表级排他锁。

再例如：用户A修改一条数据，用户B查询记录可以，但是修改这条记录不行，修改其他记录也不行，那么A加了表级共享锁。

不同的数据隔离级别，加的锁是不一样的。

回到前面的问题，readonly属性一旦被设置后，数据库级别如果为提交读，那么同一个事务中，如果对两次结果集进行查询，中间间隔修改数据库，那么应该会是同一个结果集，相当于查询的时候采用的是重复读的隔离级别。

赞 (0)

相关推荐

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

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

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

  • 浅析MYSQL REPEATABLE-READ隔离级别

    REPEATABLE-READ 即可重复读,set autocommit= 0或者START TRANSACTION状态下select表的内容不会改变.这种隔离级别可能导致读到的东西是已经修改过的. 比如: 回话一中读取一个字段一行a=1 在回话二里这个字段该行修改a=0,并且提交 回话一中再update这个字段a=0,会发现受影响行数是0,这样就可以根据受影响行数是0还是1判断此次修改是否成功! 这在某些程序里会很有用! 会话1: mysql> set autocommit=0; Query

  • MySQL中Innodb的事务隔离级别和锁的关系的讲解教程

    MySQL中Innodb的事务隔离级别和锁的关系的讲解教程

    前言: 我们都知道事务的几种性质,数据库为了维护这些性质,尤其是一致性和隔离性,一般使用加锁这种方式.同时数据库又是个高并发的应用,同一时间会有大量的并发访问,如果加锁过度,会极大的降低并发处理能力.所以对于加锁的处理,可以说就是数据库对于事务处理的精髓所在.这里通过分析MySQL中InnoDB引擎的加锁机制,来抛砖引玉,让读者更好的理解,在事务处理中数据库到底做了什么. 一次封锁or两段锁? 因为有大量的并发访问,为了预防死锁,一般应用中推荐使用一次封锁法,就是在方法的开始阶段,已经预先知道会

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

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

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

  • 深入理解Mysql的四种隔离级别

    深入理解Mysql的四种隔离级别

    一.首先什么是事务? 事务是应用程序中一系列严密的操作,所有操作必须成功完成,否则在每个操作中所作的所有更改都会被撤消.也就是事务具有原子性,一个事务中的一系列的操作要么全部成功,要么一个都不做. 事务的结束有两种,当事务中的所以步骤全部成功执行时,事务提交.如果其中一个步骤失败,将发生回滚操作,撤消撤消之前到事务开始时的所以操作. 二.事务的 ACID 事务具有四个特征:原子性( Atomicity ).一致性( Consistency ).隔离性( Isolation )和持续性( Dura

  • MySQL 四种事务隔离级别详解及对比

    MySQL 四种事务隔离级别详解及对比 按照SQL:1992 事务隔离级别,InnoDB默认是可重复读的(REPEATABLE READ).MySQL/InnoDB 提供SQL标准所描述的所有四个事务隔离级别.你可以在命令行用--transaction-isolation选项,或在选项文件里,为所有连接设置默认隔离级别. 例如,你可以在my.inf文件的[mysqld]节里类似如下设置该选项: transaction-isolation = {READ-UNCOMMITTED | READ-CO

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

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

    SQL标准定义了4类隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的.低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销. Read Uncommitted(读取未提交内容)        在该隔离级别,所有事务都可以看到其他未提交事务的执行结果.本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少.读取未提交的数据,也被称之为脏读(Dirty Read). Read Committed(读取提交内容)        这是大多数数据库系统的默认隔离

  • mysql 详解隔离级别操作过程(cmd)

    mysql 详解隔离级别操作过程(cmd)

    读未提交示例操作过程-Read uncommitted 1.打开两个MySql的命令提示行,均进入相同数据库,并检查当前表内容为相同数据如下: 2.在A.B两端执行select @@tx_isolation;检查当前默认的隔离级别别,可以发现都是 Repeatable Read –可重复读-(在当前事务内,重复读取第一次读取过的数据就叫可重复读.) 3.修改A端的隔离级别为readuncommitted –读未提交.意思是可以读取别人没有提交的数据. set transactionisolati

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

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

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

  • 详解MySQL 数据库隔离级别与MVCC

    Mysql是我们日常生产与学习中最常接触到的数据库之一,今天讲一讲在Mysql(或者说其他类似的数据库)中存在的隔离级别以及用来提高效率的多版本并发控制(MVCC). 一.隔离级别 首先我们需要提到一个概念:事务.什么是事务?事务就是完成一个基础操作的一系列操作语句的一个集合.例如我要将200元从账户A转移到账户B,那么我可能会进行一下的操作: a.验证账户A中的余额是否大于200元. b.将账户A中的余额减200元. c.将账户B中的余额加200元. 我们就将上面的abc三个操作成为一个事务.

  • mysql数据库隔离级别详解

    mysql数据库隔离级别详解

    目录 隔离级别 一.mysql有四个事务隔离级别 二.为什么默认RR隔离级别? 三.RR隔离级别下手动加锁解决幻读理论基础 脏读.不可重复读.幻读 及其解决方法 事务隔离级别命令行操作 操作验证 一.实现脏读 二.操作验证--实现不可重复读 三.操作验证--解决不可重复读 四.操作验证--实现幻读 总结 隔离级别 一.mysql有四个事务隔离级别 每个级别都有字符或数字编号 读未提交 READ UNCOMMITTED | 0 : 存在脏读,不可重复度,幻读的问题. 读已提交 READ COMMI

  • Spring事务隔离级别简介及实例解析

    Spring事务隔离级别简介及实例解析

    本文研究的主要是Spring事务隔离级别(solation level)介绍及例子,具体如下. 当两个事务对同一个数据库的记录进行操作时,那么,他们之间的影响是怎么样的呢?这就出现了事务隔离级别的概念.数据库的隔离性与并发控制有很大关系.数据库的隔离级别是数据库的事务特性ACID的一部分.ACID,即原子性(atomicity).一致性(consistency).隔离性(isolation)和持久性(durability).Spring的事务隔离级别有四个:READ_UNCOMMITTED.RE

  • mysql事务和隔离级别底层原理浅析

    mysql事务和隔离级别底层原理浅析

    目录 前言 一.事务底层原理浅析 原子性: 持久性 隔离性: 一致性: 二.隔离级别底层原理浅析 三.总结 前言 首先回顾一下什么是事务,事务是数据库操作的最小工作单元,是作为单个逻辑工作单元执行的一系列操作:这些操作作为一个整体一起向系统提交,要么都执行.要么都不执行:事务是一组不可再分割的操作集合(工作逻辑单元). 事务的特性: 原子性(Atomicity):原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚.一致性(Consistency):事务执行的结果必须是使数据库从一个一致性

  • MySQL事务的隔离级别详情

    MySQL事务的隔离级别详情

    目录 一.隔离级别的概念 二.测试TRANSACTION_READ_UNCOMMITTED隔离级别 三.测试TRANSACTION_READ_COMMITTED隔离级别 四.测试TRANSACTION_REPEATABLE_READ隔离级别 五.测试TRANSACTION_SERIALIZABLE隔离级别 一.隔离级别的概念 为什么要考虑隔离级别? 因为事务要并发执行,而并发执行可能会出现一些问题:脏读.不可重复读和虚读,有的是允许出现的,有的不允许出现,对于这种不同程度上的出现或不出现的并发控

  • 详解MySQL事务的隔离级别与MVCC

    事务隔离级别 事务并发执行遇到的问题 脏写 如果一个事务修改了另一个未提交事务修改过的数据,那就意味着发生了脏写 脏读 如果一个事务读到了另一个未提交事务修改过的数据,那就意味着发生了脏读 不可重复读 如果一个事务只能读到另一个已经提交的事务修改过的数据,并且其他事务每对该数据进行一次修改并提交后,该事务都能查询到最新值,那就意味着发生了不可重复读 幻读 如果一个事务先根据某些条件查询出一些记录,之后另一个事务又向表中插入了符合这些条件的记录,原先的事务再次按照该条件查询时,能把另一个事务插入的

  • MYSQL事务的隔离级别与MVCC

    MYSQL事务的隔离级别与MVCC

    目录 前言 1. 事务(transaction)的起源 1.1. 事务的定义 1.2. 哪些存储引擎支持事务 2. MySQL的事务语法 2.1. 自动提交 2.2. 手动操作事务 2.2.1. 开启事务 2.2.2. 提交或回滚 2.3. autocommit系统变量 3. 事务并发执行导致的读问题 3.1. 脏读 3.2. 不可重复读 3.3. 幻读 4. 回答一些可能存在的问题 5. SQL标准与4种隔离级别 5.1. 为什么要设置隔离级别? 5.2. 蹩脚的中文翻译 5.3. 为什么单单

  • Mysql事务的隔离级别(脏读+幻读+可重复读)

    Mysql事务的隔离级别(脏读+幻读+可重复读)

    目录 一.事务 (一)什么是事务 (二)事务的特征 (三)手动开启.提交.回滚事务 二.脏读.幻读.可重复读 (一)脏读 read uncommit (二)不可重复读 unrepeatable (三)幻读 (四)不可重复读和幻读的区别 三.事务的隔离级别 (一)读未提交read uncommitted (二)读已提交read committed (三)不可重复读 read repeatable (四)序列化 serializable 前言: 因为InnoDB是支持事务的,所以只对InnoDB的事

  • 全面解析MySQL中的隔离级别

    全面解析MySQL中的隔离级别

    数据库并发的对同一批数据进行增删改,就可能会出现我们所说的脏写.脏读.不可重复读.幻读等一系列问题.MySQL提供了一系列机制来解决事务并发问题,比如事务隔离.锁机制.MVCC多版本并发控制机制.今天来探究一下事务隔离机制. 事务是一组SQL组成的逻辑处理单元,先来看下事务的ACID特性: 原子性(Atomicity) :事务是一个原子操作单元,对数据进行修改,要么全执行要么全不执行.是从执行层面上来描述的. 一致性(Consistent) :在事务开始和完成时,数据都必须保持一致状态.是从执行

随机推荐