事务隔离级别

MYSQL事件隔离级别以及复读,幻读,脏读的理解

一曲冷凌霜 提交于 2019-12-25 00:41:14
一.mysql事件隔离级别 1未提交读(READUNCOMMITTED) 另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据(脏读)( 隔离级别最低,并发性能高 ) 2…提交读(READCOMMITTED) 本事务读取到的是最新的数据(其他事务提交后的)。问题是,在同一个事务里,前后两次相同的SELECT会读到不同的结果(不重复读)。会出现不可重复读、幻读问题(锁定正在读取的行) 3.可重复读(REPEATABLEREAD) 在同一个事务里,SELECT的结果是事务开始时时间点的状态,因此,同样的SELECT操作读到的结果会是一致的。但是,会有幻读现象(稍后解释)。会出幻读(锁定所读取的所有行) 推荐Python大牛在线分享技术 扣qun:855408893 领域:web开发,爬虫,数据分析,数据挖掘,人工智能 零基础到项目实战,7天学习上手做项目 4.串行化(SERIALIZABLE) 读操作会隐式获取共享锁,可以保证不同事务间的互斥(锁表) 二.脏读、不可重复读、幻读、复读 1.脏读 当前事务读到的数据是别的事务想要修改成为的但是没有修改成功的数据 2.不可重复读 当前事务先进行了一次数据读取,然后再次读取到的数据是别的事务修改成功的数据,导致两次读取到的数据不匹配,也就照应了不可重复读的语义 3.幻读

事务的隔离性

只愿长相守 提交于 2019-12-25 00:01:10
一、锁 1、锁的概述 InnoDB存储引擎中,事务的隔离性主要是由锁机制实现的。开发多用户的应用,很大的一个难点就在于并发访问:一方面既要最大程度地实现数据库的并发访问,另一方面又要确保每个用户能以一致的方式读取、修改数据,为此,我们需要锁机制。 锁机制是数据库系统区别于文件系统的另一个关键特性,锁机制用于管理对共享资源的并发访问,保证数据的完整性和一致性。这里的共享资源不仅仅是行数据,还包括缓冲池中的LRU列表,删除、添加、移动LRU列表中的元素时,有需要锁来保证一致性。 2、锁的类型 (1)共享/排他锁 MySQL提供了两种锁的粒度:行级锁、表级锁。一般而言,锁的粒度越小,并发度越高;锁用得越多,开销越大(锁的各种操作如获取锁、释放锁、检查锁状态等都会增加系统开销)。因此我们通常只锁定尽可能少的数据量,另外我们需要在锁开销和并发度之间找好平衡点。 InnoDB存储引擎提供两种行级锁: 共享锁(S Lock):允许事务读一行数据; 排他锁(X Lock):允许事务删除或更新一行数据。 如果事务T1已经获得行r的共享锁,那么事务T2可以立即获得行r的共享锁以读取数据(锁兼容);如果事务T1已经获得行r的共享锁/排他锁,那么事务T2要想获得行r的排他锁/共享锁或排他锁必须等待事务T1释放锁(锁不兼容)。共享锁和排他锁均用在事务中,随着事务的结束而释放。 (2)意向锁

Spring事务管理

喜你入骨 提交于 2019-12-24 20:30:57
事物管理对于企业应用来说是至关重要的,好使出现异常情况,它也可以保证数据的一致性。 spring 支持编程式事务管理和声明式事务管理两种方式。 编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理,spring推荐使用TransactionTemplate。 声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截,然后在目标方法开始之前创建或者加入一个事务,在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务,这样就不需要在业务逻辑代码中掺杂事务管理的代码,只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式),便可以将事务规则应用到业务逻辑中。 显然声明式事务管理要优于编程式事务管理,这正是spring倡导的非侵入式的开发方式。声明式事务管理使业务代码不受污染,一个普通的POJO对象,只要加上注解就可以获得完全的事务支持。和编程式事务相比,声明式事务唯一不足地方是,后者的最细粒度只能作用到方法级别,无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求,也存在很多变通的方法,比如,可以将需要进行事务管理的代码块独立为方法等等。 声明式事务管理也有两种常用的方式

Spring框架-Java(3)

北慕城南 提交于 2019-12-24 16:18:13
事务管理 回顾事务 事务:一组业务操作ABCD,要么全部成功,要么全部不成功。 特性:ACID 原子性:整体 一致性:完成 隔离性:并发 持久性:结果 隔离问题: 脏读:一个事务读到另一个事务没有提交的数据 不可重复读:一个事务读到另一个事务已提交的数据(update) 虚读(幻读):一个事务读到另一个事务已提交的数据(insert) 隔离级别: read uncommitted:读未提交。存在3个问题 read committed:读已提交。解决脏读,存在2个问题 repeatable read:可重复读。解决:脏读、不可重复读,存在1个问题。 serializable :串行化。都解决,单事务。 mysql 事务操作--简单 ABCD 一个事务 Connection conn = null; try{ //1 获得连接 conn = ...; //2 开启事务 conn.setAutoCommit(false); A B C D //3 提交事务 conn.commit(); } catche(){ //4 回滚事务 conn.rollback(); } mysql 事务操作--Savepoint 需求:AB(必须),CD(可选) Connection conn = null; Savepoint savepoint = null; //保存点,记录操作的当前位置

mysql基础学习二

帅比萌擦擦* 提交于 2019-12-24 04:00:39
视图 视图概念 视图是存储的查询语句,当调用的时候,产生结果集,视图充当的是虚拟表的角色。其实视图可以理解为一个表或多个表中导出来的表,作用和真实表一样,包含一系列带有行和列的数据 视图中,用户可以使用SELECT语句查询数据,也可以使用INSERT,UPDATE,DELETE修改记录,视图可以使用户操作方便,并保障数据库系统安全,如果原表改名或者删除则视图也失效。 视图操作 创建视图 语法结构: CREATE [ OR REPLACE ] VIEW [ view_name ] AS [ SELECT_STATEMENT ] ; 释义: CREATE VIEW : 创建视图 OR REPLACE : 可选,如果添加原来有同名视图的情况下会覆盖掉原有视图 view_name : 视图名称 SELECT_STATEMENT : SELECT 语句 e . g . create view c1 as select name , age from class_1 ; 视图表的增删改查操作 视图的增删改查操作与一般表的操作相同,使用insert update delete select即可,但是原数据表的约束条件仍然对视图产生作用。 删除视图 drop view [IF EXISTS] 视图名; IF EXISTS 表示如果存在,这样即使没有指定视图也不会报错。 drop view c1 ;

MySQL锁技术详解

隐身守侯 提交于 2019-12-23 18:11:56
Mysql锁技术详解 本文只讨论InoDB存储引擎下的锁。 前言 在分布式并发的场景下,对于共享资源的操作是非原子性的,这会造成操作和预期的结果并不一致。 原子性操作 :指在一次CPU的调度时间类完成的一系列操作,顺序不可打乱,也不可只执行一部分。 任何可能能被CPU打断的操作都不是原子操作,所以真正的原子操作需要硬件支持,但是硬件大多数只支持系统的核心方法的原子操作,所以如果想要在自己开发的程序里做原子操作,需要引入锁。在线程A操作共享资源时需要拿到锁,这样即便线程A的操作中途CPU切换到了线程B,线程B想要读取共享资源时缺拿不到锁,所以线程B无法操作共享资源,这样就模拟出了原子操作,保证了线程A的逻辑是完整正确的。 MySQL的事务具有原子性,所以MySQL肯定实现了许多锁来保证原子操作。以InoDB为例,来看看MySQL实现了哪些锁,这些锁又分别有什么作用。 根据锁的范围来分类,大致分为了三类锁: 全局锁 表锁 行锁 全局锁 顾名思义,全局锁就是对整个数据库实例都加上锁,命令行是 Flush tables with read lock,一旦数据库加上此锁,除了当前操作线程之外,其他的线程对数据库的增删改操作都会被阻塞,包括建表,修改表结构事务更新等操作。 全局锁一般用于数据备份,为了保证备份的一致性,加上全局锁确保备份时间类数据库里的数据不会有更新。

mysql锁机制总结

≯℡__Kan透↙ 提交于 2019-12-23 17:50:53
1. 隔离级别 (1) 读不提交 (Read Uncommited , RU) 这种隔离级别下,事务间完全不隔离,会产生脏读,可以读取未提交的记录,实际情况下不会使用。 (2) 读提交 (Read commited , RC) 仅能读取到已提交的记录,这种隔离级别下,会存在幻读现象,所谓幻读是指在同一个事务中,多次执行同一个查询,返回的记录不完全相同的现象。幻读产生的根本原因是,在 RC 隔离级别下,每条语句都会读取已提交事务的更新,若两次查询之间有其他事务提交,则会导致两次查询结果不一致。虽然如此,读提交隔离级别在生产环境中使用很广泛。 (3) 可重复读 (Repeatable Read, RR) 可重复读隔离级别解决了不可重复读的问题,但依然没有解决幻读的问题。那么不可重复读与幻读有什么区别呢?不可重复读重点在修改,即读取过的数据,两次读的值不一样;而幻读则侧重于记录数目变化【插入和删除】。一般教科书上告诉我们只有到串行化隔离级别才解决幻读问题,但mysql的innodb比较特殊,RR即解决了幻读问题,主要通过GAP锁实现。另外, 不是所有的数据库都实现了该隔离级别,后面会简单介绍下 mysql 是如何实现可重复读隔离级别的。 (4) 串行化 (Serializable) 在串行化隔离模式下,消除了脏读,幻象,但事务并发度急剧下降,事务的隔离级别与事务的并发度成反比

持久层框架-----JDBC篇(2)

断了今生、忘了曾经 提交于 2019-12-23 15:14:37
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 掌握了JDBC最基本的与数据库交互后,接下来,我们要修炼进阶篇了,此篇涉及大量的专业名词,需要有一定天赋的修行者修炼,不过,我相信,能够轻松通过第一篇的你,绝对是那个骨骼精奇,天资聪慧的修行者~那么,我们进入此次的修行把---JDBC的事务管理 事务:在一个业务场景中,保持一系列操作的整体性,我们称作事务~简单来讲,在一系列的操作中,要么,所有操作都生效,要么所有操作都不生效,不存在某些操作生效,某些操作不生效的情况。举个例子~业务场景:小鱼儿转10定金子给花无缺;涉及的操作:1.钱从小鱼儿的兜里转出~2.钱转入到花无缺的兜中~,两个操作缺一不可,如果操作1在途中受阻,那么钱就会回到小鱼儿的兜中,只有这样,才能保证我业务操作的完整性。 事务的特性: 1、原子性(atomicity):组成事务的语句形成了一个逻辑单元,不能只执行一部分; 2、一致性(consistency):在事务处理执行前后,数据库与理论值是一致的(数据库完整性约束); 3、隔离性(isolcation):一个事务处理和另一个事务处理相互间互不影响; 4、持续性(durability):事务处理的效果能够被永久保存下来。 隔离级别: 1、多线程并发执行可能会产生以下三个问题:   脏读(dirtyreads)

数据库事务

你说的曾经没有我的故事 提交于 2019-12-23 06:54:45
四种隔离级 1,read uncommitted(读取未提交内容) 在read uncommitted隔离级,所有事务都可以“看到”未提交事务的执行结果。在这种级别上,可能会产生很多问题,除非用户真的知道自己在做什么,并且很多的理由选择这样做。本隔离级别很少用于实际应用,因为它的性能也不必其他级别好多少,而别地级别还有其他更多的优点。读取未提交数据,也被称之为脏读(dirty read)。 2,read committed(读取提交内容) 大多数数据库系统的默认隔离级别为read committed(但不是mysql默认的)。它满足了隔离级别早先简单定义:一个事务在开始时,只能”看见“已经提交事务所做得改变,一个事务从开始到提交前,所做得任何数据改变都是不可见的,除非已经提交。这种隔离级别也支持 所谓的”不可重复读(nonrepeatable)“,意味着用户运行同一语句两次,看到的结果是不同的。 3,repeatable read(可重读) repeatable read隔离级解决了read uncommitted隔离级导致的问题。它却确保同一事务的多个实例在并发读取数据时,会”看到同样地“数据行。不过理论上,这会导致另外一个棘手的问题,幻读(phantom read)。简单来说,幻读指当用户读取某一个范围的数据行时,另外一个事务又在该范围内插入插入了心行

MySQL事务以及隔离级别

怎甘沉沦 提交于 2019-12-23 06:54:32
前言: 我一直想不到一个好的标题应该怎么写。我想MySQL的一些重要的内容。我在两次面试中都遇到过的,但直接用MySQL标题好像又不太贴切。干脆就是所写的内容吧。 MySQL事务: transaction Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back. Database transactions, as implemented by InnoDB , have properties that are collectively known by the acronym ACID, for atomicity, consistency, isolation, and durability. See Also ACID , commit , isolation level , lock , rollback