事务隔离级别

1.4多版本并发控制 Mysql的大多数事务型存储引擎的实现都不是基于简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制（MVCC）。它的实现是通过保存数据再某个时间点的快照来实现的。当一个事务开始进行时，他无论花了多少时间执行多少次相同的查询，他看到的数据都是一致的。而不同的事务在不同时间点开始事务时，每个事务对同一张表、同一个时刻看到的数据可能都是不相同的。 以最经典的InnoDB引擎（隔离级别为REPEATABLE READ）为例，它的MVCC实现方法是通过在每行记录后面保存两个隐藏列来实现的。一个列保存行的创建时间，一个列用来保存列的过期时间（删除时间），他存储的不是实际的时间值，而是系统版本号，每当开始一个新的事务，系统版本号就会自动递增，该事务开始的时刻的版本号即为该事务的版本号，用来和该事务要查询的每行记录的版本号进行比较。 SELECT： InnoDB会根据以下两个条件检查每行记录： a.InnoDB只会查找版本小于或等于当前事务版本的数据行，这样可以保证事务读取的行要么在事务开始前已经存在了，要么是事务他自身插入或修改过的行。 b.行的删除版本要么未定义，要么要大于当前事务的版本号。这可以确保事务读取到的行，一定是在该事务开始时未被删除的数据行。 INSERT/DELETE： InnoDB为新插入（新删除的

数据库事务：一件完整的事情， 要么全部成功，要么就全部失败 金典案例：转账 A给B转账：100 A:-100 B:+100 如何开启事务： Start transaction; 之前的转账操作（如果在转账过程中出现异常：rollback） Commit; 事务的特性（ACID）: 原子性：要么全部成功 要么全部失败 不可以分割 一致性：事务前后，所有的状态都要保持一致 隔离性：一个事务最好不要受到其他事务的影响 持久性：将提交或者回滚的事务 存储到数据库中 不考虑隔离性： 脏读：读取到另一个事务中未提交的数据 不可重复读：在同一个事务中，两次查询结果不一样（update） 虚读（幻读）：在同一个事务中，两次查询结果不一样（insert） 隔离级别： 1）read uncommitted : 读取尚未提交的数据 ：哪个问题都不能解决 2）read committed：读取已经提交的数据 ：可以解决脏读 ---- oracle默认的 3）repeatable read：重读读取：可以解决脏读 和 不可重复读 ---mysql默认的 4）serializable：串行化：可以解决 脏读 不可重复读 和 虚读---相当于锁表 查看数据库的隔离级别： Select @@tx_isolation; Mysql 默认的隔离级别：repeatable-read; Oracle ： read

大纲 1.什么是事务？ 2.事务的四大特性ACID 3.数据库的四种隔离级别 4.事务并发执行会出现的问题 1.什么是事务（Transaction）？ 　　一组操作，要么全部执行成功，要么全部不执行。事务由一组操作组成，其中任一操作发生错误，则回滚之前成功的操作。 2.数据库事务的四大特性ACID 　　 原子性（Atomicity） ：事务是一个不可分割的执行单元，事务包含的全部操作要么全部执行成功，要么全部失败回滚。也即成功则完全应用到数据库，失败则对数据库不产生任何变更。 　　 一致性（Consistency） ：事务开始前和结束后， 数据库的完整性约束（存储在数据库中的所有值都是正确的） 没被破坏。 　　 隔离性（Isolation） ：每个事务相互独立，互不干扰，一个事务无法看到另一个事务中的数据。 　　 持久性（Durability） ：事务执行完成，其结果是持久化保存的。即使数据库发生崩溃，数据库恢复后事务提交的结果仍然存在（当然如果数据无法恢复的另说）。 3.数据库的四种隔离级别 　　 Serializable (串行化)： 可避免脏读、不可重复读、幻读的发生。 　　 Repeatable read (可重复读)： 可避免脏读、不可重复读的发生。 　　 Read committed (读已提交)： 可避免脏读的发生。 　　 Read uncommitted (读未提交

原始bean.xml配置文件内容如下： <!-- 0.从外部加载数据源 1.创建连接池 DriverManagerDataSource 设置4个属性 2.创建JdbcTemplate, 注入dataSource --> <!-- 0.从外部加载数据源 --> <context:property-placeholder location="classpath:db.properties"/> <!--1.创建连接池 DriverManagerDataSource 设置4个属性--> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName" value="${jdbc.driverClassName}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> <!--2.创建JdbcTemplate, 注入dataSource-->

@Transactional注解是为方法添加事务块的意思，使用aop的技术动态为方法添加事务范围，在使用它时可以在类或者方法上添加，但在类上添加时需要注意一下影响的范围。 类中添加Transactional 相当于你的每个公共的方法都会被迫加上事务，这并不是一件好事，所以不建议这样干。 拦截器里调用的Bean 在ｈｔｔｐ的拦截器里，调用了一个类，这个类是个ｂｅａｎ，而它被添加了 Transactional 注解，这相当于，你以后的每个HTTP请求都会被加上事务，这是很要命的，因为那些单表操作是不需要添加事务的。 事物传播行为介绍 @Transactional(propagation=Propagation.REQUIRED) ：如果有事务, 那么加入事务, 没有的话新建一个(默认情况下) @Transactional(propagation=Propagation.NOT_SUPPORTED) ：容器不为这个方法开启事务 @Transactional(propagation=Propagation.REQUIRES_NEW) ：不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务 @Transactional(propagation=Propagation.MANDATORY) ：必须在一个已有的事务中执行,否则抛出异常 @Transactional

本文实验的测试环境：Windows 10+cmd+MySQL5.6.36+InnoDB 一、事务的基本要素（ACID） 　　 1、原子性（Atomicity）： 事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 　　 2、一致性（Consistency）： 事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 　　 3、隔离性（Isolation）： 同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。 　　 4、持久性（Durability）： 事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 二、事务的并发问题 　　1、脏读： 事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据 　　2、不可重复读： 事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。 　　3、幻读： 系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级

原创作品，可以转载，但是请标注出处地址： http://www.cnblogs.com/V1haoge/p/6634151.html 1、回顾 　　之前介绍了Environment环境类，这其实是一个单例类，在MyBatis运行开启后只会存在一个唯一的环境实例，虽然我们可以在Configuration配置文件中配置多个环境，但是项目运行中只会存在其中的一个，一般项目会存在开发环境和测试环境、生产环境三大环境，其是否可以设置到配置文件中，在开发时使用开发环境，测试时使用测试环境，正式运营时可以使用生产环境。 　　之前还提到Environment类中有三个字段，除了id之外，TransactionFactory和DataSource都是比较复杂的模块，这一次我们介绍Transaction模块（即事务模块）。 2、事务模块 　　事务模块位于 org.apache.ibatis.transaction 包，这个包内的类均是事务相关的类： 　　org.apache.ibatis.transaction 　　-----org.apache.ibatis.transaction.jdbc 　　----------JdbcTransaction.java 　　----------JdbcTransactionFactory.java 　　-----org.apache.ibatis

详见：https://www.cnblogs.com/softidea/p/5877546.html Spring Boot 使用事务非常简单，首先使用注解 @EnableTransactionManagement 开启事务支持后，然后在访问数据库的Service方法上添加注解 @Transactional 便可。 关于事务管理器，不管是JPA还是JDBC等都实现自接口 PlatformTransactionManager 如果你添加的是 spring-boot-starter-jdbc 依赖，框架会默认注入 DataSourceTransactionManager 实例。如果你添加的是 spring-boot-starter-data-jpa 依赖，框架会默认注入 JpaTransactionManager 实例。 你可以在启动类中添加如下方法，Debug测试，就能知道自动注入的是 PlatformTransactionManager 接口的哪个实现类。 @EnableTransactionManagement // 启注解事务管理，等同于xml配置方式的 <tx:annotation-driven /> @SpringBootApplication public class ProfiledemoApplication { @Bean public Object

transaction本意是买卖、交易。数据库世界为了强调数据的原子性，中译为 事务。 SQL标准规定不同隔离级别下产生的问题不同，会出现脏读、幻读与不可重复读的现象。对应四种事务的隔离级别： Read UnCommitted 会出现脏读、幻读与不可重复读现象 ReadCommitted 只会出现幻读与不可重复读现象 Repeatable Read 只会出现幻读现象 Serializable 串行执行 不过，各种数据库实现对SQL标准支持不同。 解决脏读、幻读与不可重复读的现象的两种解决方案： 方案一：读操作使用mvcc，写操作加锁 mvcc也叫版本链。每条聚簇索引叶子节点的记录都有隐藏的列：trx_id与roll_pointer，每个事务都有唯一的id。在操作记录时，又会产生undo日志，undo日志形成的链表的引用就保存在roll_pointer位置。 在读取一条记录时，通过快照生成一个ReadView的结构，他会记录当前系统中正活动的事务id，遍历roll_pointer的版本链进行对比，如果ReadView里包含undo的事务id，则证明该事务并没有提交，不能采用此日志的处理结果。一直遍历得到的事务id不在ReadView里，并且小于ReadView的最小事务id(因为事务id有全局变量记录并递增，小的事务id说明产生的更早)的事务，则返回此事务处理后的结果。 简单的说

在 数据库的锁机制 中介绍过，数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。 乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。 无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。 针对于不同的业务场景，应该选用不同的并发控制方式。所以，不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。 下面来分别学习一下悲观锁和乐观锁。 悲观锁 在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。 悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。 悲观锁，正如其名，它指的是对数据被外界