隔离级别

★　 脏读　　　　： 读取了前一事务 未提交 的数据 ; 　　不可重复读 ： 读取了前一事务 提交 的数据； ★　幻读 与 不可重复读　　　　 　　common　　：都是读取了另一条已经提交的事务（这点与脏读不同）； 　　differences ： 　　　　不可重复读 ：查询的都是同一个数据项 　　　　幻读 　　 ：针对的是一批数据整体（比如数据的个数） 不可重复读eg: 　　< 当隔离级别设置为Repeatable read 时，可以避免不可重复读 > 　　eg2: 在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。 　　　　与此同时，事务B把张三的工资改为8000，并提交了事务。 　　　　随后，在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。(大部分数据库缺省的事物隔离级别都不会出现这种状况) 幻读eg: 　　eg1: 目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。 　　　　此时，事务B插入一条工资也为5000的记录，并且commit了。 　　　　这时，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。 　　　　(大部分数据库缺省的事物隔离级别都会出现这种状况，此种事物隔离级别将带来表级锁) 　　eg2：

事务隔离级别：一个事务对数据库的修改与并行的另一个事务的隔离程度。 两个并发事务同时访问数据库表相同的行时，可能存在以下三个问题： 1、 幻想读 ：事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新纪录就是幻想。 2、 不可重复读取 ：事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录，然后T1再次查询，发现与第一次读取的记录不同，这称为不可重复读。 3、 脏读 ：事务T1更新了一行记录，还未提交所做的修改，这个T2读取了更新后的数据，然后T1执行回滚操作，取消刚才的修改，所以T2所读取的行就无效，也就是脏数据。 为了处理这些问题，SQL标准定义了以下几种事务隔离级别 READ UNCOMMITTED 幻想读、不可重复读和脏读都允许。 READ COMMITTED 允许幻想读、不可重复读，不允许脏读 REPEATABLE READ 允许幻想读，不允许不可重复读和脏读 SERIALIZABLE 幻想读、不可重复读和脏读都不允许 Oracle数据库支持READ COMMITTED 和 SERIALIZABLE这两种事务隔离级别。所以Oracle不支持脏读 SQL标准所定义的默认事务隔离级别是SERIALIZABLE，但是Oracle

目录 1 脏读 2 不可重复读 3 幻读 数据库的事务隔离级别 读未提交（Read Uncommitted） 读提交（Read Committed） 可重复读(Repeated Read) 串行化（Serializable） 总结 丢失更新 ：两个事务同时更新一行数据，最后一个事务的更新会覆盖掉第一个事务的更新，从而导致第一个事务更新的数据丢失，这是由于没有加锁造成的 1 脏读 脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。 2 不可重复读 不可重复读 是指在一个事务内，多次读同一数据。 在这个事务还没有结束时，另外一个事务也访问该同一数据。 那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。 这样在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。 3 幻读 幻读 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。 同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。 那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样 数据库的事务隔离级别 什么是事务隔离？ 任何支持事务的数据库，都必须具备四个特性

从Spring 事务配置说起 　　先看看Spring 事务的基础配置 <aop:aspectj-autoproxy proxy-target-class="true"/> 　　<bean id="transactionManager" 　　　　class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> 　　　　<property name="dataSource" ref="dataSource"/> 　　</bean> 　　<tx:annotation-driven transaction-manager="transactionManager"/> 　　<!-- 配置事务传播特性--> 　　<tx:advice id="transactionAdvice" transaction-manager="transactionManager"> 　　　　<tx:attributes> 　　　　　　<tx:method name="add*" propagation="REQUIRED" 　　　　　　rollback-for="Exception,RuntimeException,SQLException"/> 　　　　　　<tx:method name="remove*" propagation=

一、Spring事务传播属性（Propagation）： 1) REQUIRED（默认属性） 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。 被设置成这个级别时，会为每一个被调用的方法创建一个逻辑事务域。如果前面的方法已经创建了事务，那么后面的方法支持当前的事务，如果当前没有事务会重新建立事务。 2) MANDATORY 支持当前事务，如果当前没有事务，就抛出异常。 3) NEVER 以非事务方式执行，如果当前存在事务，则抛出异常。 4) NOT_SUPPORTED 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 5) REQUIRES_NEW 新建事务，如果当前存在事务，把当前事务挂起。 6) SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行。 7) NESTED 支持当前事务，新增Savepoint点，与当前事务同步提交或回滚。 嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。 PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别： 它们非常类似，都像一个嵌套事务，如果不存在一个活动的事务，都会开启一个新的事务。 使用PROPAGATION_REQUIRES_NEW时

1. 事务的ACID 事务的ACID是指事务拥有的4个特性的首字母组合：atomicity(原子性), consistency(一致性), isolation(隔离性)和durability(持久性)。 ①atomicity(原子性) ：表示事务是一个不可分割的工作单元，要么在提交事务后所有更改成功，要么在回滚事务时撤消所有更改，不可以只执行其中的一部分操作。 ②consistency(一致性) ：在每次提交、回滚之后或正在进行的事务，数据库始终保持一致状态。如正在跨多个表更新相关数据，则查询看到的将是所有旧值或所有新值，而不是新值和旧值的混合。 ③isolation(隔离性) ：事务在进行过程中相互隔离，他们不能互相干扰，也不能看到彼此的未提交数据。 但可以通过修改隔离级别，查看其他事务正在处理的数据。 ④durability(持久性) ：事务提交成功后，该事务所做的更改将会保存在数据库中。 2. 并发读取数据的问题 当事务读取另一个事务已修改的数据时，可能会发生dirty read(脏读)、non-repeatable read(不可重复读)和phantom read(幻读)之类的现象。 ①dirty read(脏读) ：当前事务读取了另一个事务已更新但尚未提交的数据。后果就是另一个事务回滚了，此数据就为错误的无效数据。 ②non-repeatable read(不可重复读)

1，事务具有acid特性 2，事务的隔离级别 　　事务的隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。MySQL事务包含4个隔离级别（从低到高） 　　1）read uncommitted（dirty read）也称读未提交。事务可以看到其他事务更改了但没有提交的数据，即存在脏读的情况。 　　2）read committed 也称读提交。事务可以看到在它执行的时候，其他事务已经提交的数据，已经被大部分数据库采用。允许不可重复读，但不允许脏读。 　　3）repeatable read 也称可重复读。同一个事务同一个查询请求多次执行，获得记录相同，但不能出现幻读。 　　4）serializable也称序列化，最高级别，解决了幻读。它将锁加在所有访问的数据上。 　　该锁把普通的select语句默认改成select 。。。lock in share mode。 即查询语句涉及到的数据加上共享锁，阻塞其他事务修改真实的数据。 　如下命令查询当前事务的隔离级别 show variables like ‘%tx%’; 　不建议更改innodb的事务隔离级别。一些传统的数据库，如oracle使用了read-commited的隔离级别。但是大部分场景下，MySQL的用户都是由默认的repeatable read，此隔离级别下使用的验证比其他的隔离级别完善的多

事务的属性 propagation：用来设置事务的传播行为 事务的传播行为：一个方法运行在了一个开启了事务的方法中，当前方法是使用原来的事务还是开启一个新的事务 Propagation.REQUIRED：默认值，使用原来的事务 Propagation.REQUIRES_NEW：将原来的事务挂起，开启一个新的事务 isolation：用来设置事务的隔离级别 Isolation.REPEATEBLE_READ：可重复读，MySQL默认的隔离级别 Isolation.READ_COMMITTED：读已提交，Oracle默认的隔离级别，开发时通常使用的隔离级别 事务的传播简介 当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。例如：方法可能继承在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。 事务的传播行为可以由传播属性指定。Spring定义了7种类型的传播行为。 传播属性 描述 REQUIRED （默认） 如果有事务在运行，当前的方法就在这个事务内运行，否则，就启动一个新的事务，并在自己的事务内运行 REQUIRES_NEW 当前的方法必须启动新的事务，并在它自己的事务内运行，如果有事务正在运行，应该将它挂起 SUPPORTS 如果有事务正在运行，当前的方法就在这个事务内运行。否则它可以不运行在事务中 NOT_SUPPORTED 当前的方法不应该运行在事务中

天天用事务，但是你知道MySQL事务的实现原理吗？ 1. 开篇 相信大家都用过事务以及了解他的特点，如原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability)等。今天想跟大家一起研究下事务内部到底是怎么实现的，在讲解前我想先抛出个问题： 事务想要做到什么效果？ 按我理解，无非是要做到可靠性以及并发处理。 可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离级别。 下面我首先讲实现事务功能的三个技术，分别是日志文件(redo log 和 undo log)，锁技术以及MVCC，然后再讲事务的实现原理，包括原子性是怎么实现的，隔离型是怎么实现的等等。最后在做一个总结，希望大家能够耐心看完 redo log与undo log介绍 mysql锁技术以及MVCC基础 事务的实现原理 总结 2 redo log 与 undo log介绍 1. redo

原文: 高性能MySQL之事务 背景 当你手中抓住一件东西不放时，你只能拥有一件东西，如果你肯放手，你就有机会选择更多。与其在别人的生活里跑龙套，不如精彩做自己。人无所舍，必无所成。跌倒了，失去了，不要紧，爬起来继续风雨兼程，且歌且行。 一、概念 事务到底是什么东西呢？想必大家学习的时候也是对事务的概念很模糊的。接下来通过一个经典例子讲解事务。 银行在两个账户之间转账，从A账户转入B账户1000元，系统先减少A账户的1000元，然后再为B账号增加1000元。如果全部执行成功，数据库处于一致性；如果仅执行完A账户金额的修改，而没有增加B账户的金额，则数据库就处于不一致状态，这时就需要取消前面的操作。这过程中会有一系列的操作，比如余额查询，余额做加减法，更新余额等，这些操作必须保证是一个整体执行，要么全部成功，要么全部失败，不能让A账户钱扣了，但是中途某些操作失败了，导致B账户更新余额失败。这样用户就不乐意了，银行这不是坑我吗？因此简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。 接下来会以InnoDB为例，抽丝剥茧MySQL在事务支持方面的特定实现