事务隔离级别

事务ACID特性，其中I代表隔离性(Isolation)。 什么是事务的隔离性？ 隔离性是指，多个用户的并发事务访问同一个数据库时，一个用户的事务不应该被其他用户的事务干扰，多个并发事务之间要相互隔离。 一个事务怎么会干扰其他事务呢？ 咱们举例子来说明，假设有InnoDB表： t(id PK, name); 表中有三条记录： 1, shenjian 2, zhangsan 3, lisi case 1 事务A，先执行，处于未提交的状态： insert into t values(4, wangwu); 事务B，后执行，也未提交： select * from t; 如果事务B能够读取到(4, wangwu)这条记录，事务A就对事务B产生了影响，这个影响叫做“读脏”，读到了未提交事务操作的记录。 case 2 事务A，先执行： select * from t where id=1; 结果集为： 1, shenjian 事务B，后执行，并且提交： update t set name=xxoo where id=1; commit; 事务A，再次执行相同的查询： select * from t where id=1; 结果集为： 1, xxoo 这次是已提交事务B对事务A产生的影响，这个影响叫做“不可重复读”，一个事务内相同的查询，得到了不同的结果。 case 3 事务A，先执行：

前两天面试，问到了四种隔离级别，当时觉得大多数数据库都为read committed，结果没想到mysql是个例外。在此做一下隔离级别和各种数据库锁的使用。 首先说一下ACID四大特性： 四大特性 · 原子性 　　事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。 　　· 一致性 　　 事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部 数据结构 （如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。 　　· 隔离性 　　由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上

转自 http://blog.sina.com.cn/s/blog_499740cb0100ugs7.html MySQL InnoDB事务的隔离级别 有四级，默认是“可重复读”（REPEATABLE READ）。 未提交读（READ UNCOMMITTED）。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）。 提交读（READ COMMITTED）。本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的结果（不重复读）。 可重复读（REPEATABLE READ）。在同一个事务里，SELECT的结果是事务开始时时间点的状态，因此，同样的SELECT操作读到的结果会是一致的。但是，会有幻读现象（稍后解释）。 串行化（SERIALIZABLE）。读操作会隐式获取共享锁，可以保证不同事务间的互斥。 四个级别逐渐增强，每个级别解决一个问题。 脏读，最容易理解。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据。 不重复读。解决了脏读后，会遇到，同一个事务执行过程中，另外一个事务提交了新数据，因此本事务先后两次读到的数据结果会不一致。 幻读。解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。但是，如果另一个事务同时提交了新数据

1、Transaction（事务）是什么： 事务是作为单一工作单元而执行的一系列操作。包括增删查改。 2、事务的种类： 事务分为显示事务和隐式事务： 隐式事务：就是平常我们使用每一条sql 语句就是一个事务，只不过他们执行完成之后事务就跟着结束了。 显示事务：就是需要我们来手写了，这个时候就可以进行控制事务的开始和结束了。 1 --显式事务（对事物可以进行控制） 2 3 --开始事务 4 begin transaction; 5 update [Sales.Shippers] 6 set companyname='顺丰' where shipperid=5; 7 8 select * from [Sales.Shippers]; 9 10 --结束事务： 11 --第一种：事务的回滚 12 rollback; 13 14 --第二种：事务的提交 15 commit; 3、事务很重要的四个属性： 1、 原子性 ：事务必须是原子工作单位。——在事务中修改数据，要么全都执行，要么全都不执行。在事务执行完成之前（调提交指令写入到sql的事务日志之前），出现问题或重启，sql server 会回滚所有的修改事务。 但是也有例外的错误不会回滚事务————例如：主键冲突和锁超时等。 错误日志会 捕获这些错误的指令，并记录日志里面，然后执行一些操作（例如：回滚事务） 2、 一致性

前两天面试，问到了四种隔离级别，当时觉得大多数数据库都为read committed，结果没想到mysql是个例外。在此做一下隔离级别和各种数据库锁的使用。 首先说一下ACID四大特性： 四大特性 · 原子性 　　事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。 　　· 一致性 　　 事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部 数据结构 （如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。 　　· 隔离性 　　由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上

Innodb锁的类型 行锁（record lock） 行锁总是对索引上锁，如果某个表没有定义索引，mysql就会使用默认创建的聚集索引，行锁有S锁和X锁两种类型。 共享锁和排它锁 Innodb锁有两种类型：共享锁(S lock)和排它锁(X lock) 不同事务可以同时对同一行记录加S锁 如果一个事务对某一行记录加X锁，其他事务就不能加S锁或者X锁，从而导致锁等待 使用sql SELECT ... LOCK IN SHARE MODE 可以对一行记录加S锁，sql SELECT ... FOR UPDATE 则是加X锁 意向锁（intention lock） Innodb为了支持多粒度的加锁，允许行锁和表锁同时存在。插入意向锁即是一种表锁，在事务对某一行或者多行加锁之前，必须对这张表加入意向锁（或更强的锁如X锁）。插入意向锁分为： intention shared lock (IS)：表明事务对于这张表的记录有插入S锁的意向 intention exclusive lock (IX)：表明事务对于这张表的记录有插入X锁的意向 插入意向锁和其他表锁兼容性如下： X IX S IS X Conflict Conflict Conflict IX Conflict Compatible Conflict S Conflict Conflict Compatible IS Conflict

锁 数据库系统使用锁是为了支持对共享资源进行并发访问，提供数据的完整性和一致性。 InnoDB存储引擎中的锁 共享锁（S Lock），允许事务读一行数据 排他锁（X Lock），允许事务删除或更新一行数据 兼容性： S与S可以兼容 X不与任何锁兼容 InnoDB支持多粒度锁定，也就是允许行级和表级的锁同时存在。实现方式为通过意向锁（Intention Lock）：如果需要对最细粒度进行加锁，需要在上层粒度加意向锁。 具体举例，如果需要对行加X锁，需要对表、页依次加IX锁。当意向锁遇到等待时，必须等待结束后才能继续对下级加锁。如准备加对一行有S锁的行加S锁，行记录因为原来就有S锁，所以表和页都已经存在了IS锁，首先新的IS锁加在表上，因为IS、IS锁兼容，可以加上；然后再看页锁，同样IS、IS兼容，可以加上；最后看行锁IS与S兼容，那么行记录可以加上S锁。对同样这行有S锁的行加X锁，先加表IX锁，IX与IS兼容，可以加上，页同样，最后IX锁与行记录上的S锁不兼容，因此要等待S锁释放后才能加上X锁。 一致性非锁定读 一致性非锁定读（consistent nonlocking read）是指InnoDB存储引擎通过行多版本控制（multi version）的方式来读取当前执行时间数据库中行的数据。在行记录正在执行DELETE或UPDATE时执行读操作，不会等待锁释放

一、声明式事务管理的概括 声明式事务(declarative transaction management)是 Spring 提供的对程序事务管理的方式之一。 Spring的声明式事务顾名思义就是采用声明的方式来处理事务。这里所说的声明，就是指在配置文件中声明。用在Spring配置文件中声明式的处理事务来代替代码式的处理事务。这样的好处是，事务管理不侵入开发的组件，具体来说，业务逻辑对象就不会意识到正在事务管理之中，事实上也应该如此，因为事务管理是属于系统层面的服务，而不是业务逻辑的一部分，如果想要改变事务管理策划的话，也只需要在 定义文件 中重新配置即可；在不需要事务管理的时候，只要在设定文件上修改一下，即可移去事务管理服务，无需改变代码重新编译，这样维护起来极其方便。 Spring使用 AOP 来完成声明式的事务管理，因而声明式事务是以方法为单位，Spring的事务属性自然就在于描述事务应用至方法上的策略，在Spring中事务属性有以下四个参数： 1.传播行为 2. 隔离级别 3.只读提示 4.事务超时期间 二、aop声明式事务所需的jar包 1、aopalliance.jar 这个包是 AOP 联盟的 API 包，里面包含了针对面向切面的接口。(通常Spring等其它具备动态织入功能的框架依赖此包) 2、aspectjrt.jar　　　　 处理事务和AOP所需的包 3

@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.SERIALIZABLE, rollbackFor = Exception.class)简单解析：如果有事务，那么加入事务，没有的话新建一个； 串行化最高级隔离级别； 遇到异常回滚。 @Transactional之value value这里主要用来指定不同的事务管理器；主要用来满足在同一个系统中，存在不同的事务管理器。比如在Spring中，声明了两种事务管理器txManager1, txManager2. 然后，用户可以根据这个参数来根据需要指定特定的txManager. @Transactional之propagation（service中调用其他service时需要注意） @Transactional(propagation=Propagation.REQUIRED) 如果有事务， 那么加入事务， 没有的话新建一个(默认情况下) @Transactional(propagation=Propagation.NOT_SUPPORTED) 容器不为这个方法开启事务 @Transactional(propagation=Propagation.REQUIRES_NEW) 不管是否存在事务，都创建一个新的事务，原来的挂起，新的执行完毕

事务的定义 事务(Transaction):是并发控制的单元，是用户定义的一个操作序列。这些操作要么都做，要么都不做，是一个不可分割的工作单位。通过事务，sql server 能将逻辑相关的一组操作绑定在一起，以便服务器 保持数据的完整性。 事务的相关特性 用几个字母总结就是ACID。 1) 原子性（atomicity）：事务是数据库的逻辑工作单位，而且是必须是原子工作单位，对于其数据修改，要么全部执行，要么全部不执行。 2) 一致性（consistency）：事务在完成时，必须是所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。 3) 隔离性（isolation）：一个事务的执行不能被其他事务所影响。 4) 持久性（durability）：一个事务一旦提交，事物的操作便永久性的保存在database中。即使此时再执行回滚操作也不能撤消所做的更改。 事务处理所采用的方式 事务通常是以begin transaction开始，以commit或rollback结束。Commint表示提交，即提交事务的所有操作。具体地说就是将事务中所有对数据的更新写回到磁盘上的物理数据库中去，事务正常结束。Rollback表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续进行，系统将事务中对数据库的所有已完成的操作全部撤消，滚回到事务开始的状态。