事务隔离级别

在这里主要介绍Spring对事务管理的一些理论知识，实战方面参考上一篇博文: http://www.cnblogs.com/longshiyVip/p/5061547.html 1. 事务简介： 事务管理是企业级应用程序开发中必不可少的技术，用来确保数据的完整性和一致性 事务就是一系列的动作，它们被当作一个单独的工作单元。这些动作要么全部完成，要么全部不起作用 2. 事务的四个关键属性(ACID) ① 原子性(atomicity):事务是一个原子操作，有一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用 ② 一致性(consistency):一旦所有事务动作完成，事务就被提交。数据和资源就处于一种满足业务规则的一致性状态中 ③ 隔离性(isolation):可能有许多事务会同时处理相同的数据，因此每个事物都应该与其他事务隔离开来，防止数据损坏 ④ 持久性(durability):一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响。通常情况下，事务的结果被写到持久化存储器中 3. Spring中的事务管理 作为企业级应用程序框架，Spring在不同的事务管理API之上定义了一个抽象层。而应用程序开发人员不必了解底层的事务管理API，就可以使用Spring的事务管理机制。 Spring既支持编程式事务管理(也称编码式事务)，也支持声明式的事务管理

一、Mysql的四个隔离级别 预备工作： 先创建一个test数据库及account表， create database test;use test; create table account( id int not null, balance float not null, PRIMARY KEY ( id) ) 向account中插入两条测试数据 INSERT INTO table(id,balance) VALUES (1,1000); INSERT INTO table(id,balance) VALUES (2,1000); 　　 开启两个控制台窗口，当做两个用户（A和B） 1.1 READ UNCOMMITTED（未提交读） 也即RU，在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。 A用户操作如下： set session transaction isolation level read uncommitted; start transaction; select * from

隔离级别 数据库事务的四个基本特征（ACID） 原子性（Atomic）：事务中包含的操作被看做一个整体的业务单元，这个业务单元中的操作，要么全部成功，要么全部失败。 一致性（Consisitency）：事务在完成时，必须使所有的数据都保持一致状态，在数据库中所有的修改都基于事务，保证了数据的完整性。例，A账户有一千元，B账户有一千元，A+B = 2000元， A向B转账100元,此时A有900元，B有1100元，A+B依然是2000元。 隔离性（Isolation） :当多个线程访问同一数据，此时数据库同样的数据就会在各个不同的事务中访问，这样会产生丢失更新。例，事务A读取了事务B尚未提交的数据。为了压制丢失更新的产生，数据库定义了隔离级别的概念。 持久性（Durability）：事务结束后，所有的数据都会固化到一个地方，如保存到磁盘当中，即时断电重启也可以提供给应用程序访问。 丢失更新类型 这四个特性，除了隔离性都比较好理解。我们再举例说明下，在多个事务同时操作数据的情况下，会引发丢失更新的场景。例如，电商有一种商品，在疯狂抢购，此时会出现多个事务同时访问商品库存的情景，这样就会产生丢失更新。一般而言，存在两种类型的丢失更新。 假设某种商品A库存数量为100，抢购时，每个用户仅允许抢购一件商品，name在抢购过程中就可能出现如下场景： 可以看到，T5时刻事务1回滚

一、事务的基本要素（ACID） 事务是指多个操作单元组成的合集，多个单元操作是整体不可分割的，要么都操作不成功，要么都成功。其必须遵循四个原则（ACID）。 原子性（Atomicity）：指一个事务要么全部执行,要么不执行，也就是说一个事务不可能只执行了一半就停止了.比如你从取款机取钱,这个事务可以分成两个步骤:1划卡,2出钱.不可能划了卡,而钱却没出来.这两步必须同时完成.要么就不完成。 一致性（Consistency）：在事务执行前数据库的数据处于正确的状态，而事务执行完成后数据库的数据还是应该处于正确的状态，即数据完整性约束没有被破坏；如银行转帐，A转帐给B，必须保证A的钱一定转给B，一定不会出现A的钱转了但B没收到，否则数据库的数据就处于不一致（不正确）的状态。 隔离性（Isolation）：并发事务执行之间互不影响，在一个事务内部的操作对其他事务是不产生影响，这需要事务隔离级别来指定隔离性； 持久性（Durability）：事务一旦执行成功，它对数据库的数据的改变必须是永久的，不会因比如遇到系统故障或断电造成数据不一致或丢失。 二、数据库隔离级别 隔离级别 隔离级别的值 脏读 不可重复读 幻读 读未提交 Read-Uncommitted 0 是 是 是 不可重复读 （read-committed） 1 否 是 否 可重复读 （repeatable-read） 2 否 否

一.产生死锁的四个必要条件： （1） 互斥条件：一个资源每次只能被一个进程使用。 （2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。 （3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。 （4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。 二 锁的分类 锁的类别有两种分法： 1. 从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁 MS-SQL Server 使用以下资源锁模式。 锁模式描述: 　　共享 (S) ：读锁，用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。 　　更新 (U) ：( 介于共享和排它锁之间 ），可以让其他程序在不加锁的条件下读，但本程序可以随时更改。 　　读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK 的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。当我们用UPDLOCK来读取记录时可以对取到的记录加上更新锁，从而加上锁的记录在其它的线程中是不能更改的只能等本线程的事务结束后才能更改，我如下示例： BEGIN TRANSACTION --开始一个事务 SELECT Qty FROM myTable WITH (UPDLOCK) WHERE Id in (1,2,3) UPDATE

Reference： https://time.geekbang.org/column/article/117247 死锁产生 行锁的具体实现算法有三种：record lock、gap lock以及next-key lock。 record lock是专门对索引项加锁； gap lock是对索引项之间的间隙加锁； next-key lock则是前面两种的组合，对索引项及其之间的间隙加锁。 只在可重复读或以上隔离级别下的特定操作才会取得gap lock或next-key lock，在Select、Update和Delete时，除了基于唯一索引的查询之外，其它索引查询时都会获取gap lock或next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用gap lock或next-key lock。 在MySQL中，gap lock默认是开启的，即innodb_locks_unsafe_for_binlog参数值是disable的，且MySQL中默认的是RR事务隔离级别。 当执行以下查询SQL时，由于order_no列为非唯一索引，此时又是RR事务隔离级别，所以SELECT的加锁类型为gap lock，这里的gap范围是(4,+∞）。 1 SELECT id FROM demo.order_record where order_no = 4 for

参考了这篇文章： http://www.cnblogs.com/LBSer/p/5183300.html 《 mysql死锁问题分析 》 写的不错。 如果Mysql死锁，会报出： 1.1 死锁成因&&检测方法 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了 wait-for graph算法 来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 innodb隔离级别、索引与锁 1.2.1 锁与索引的关系 假设我们有一张消息表（msg），里面有3个字段。假设id是主键，token是非唯一索引，message没有索引。 id: bigint token: varchar(30) message: varchar(4096) innodb对于主键使用了 聚簇索引 ，这是一种数据存储方式，表数据是和主键一起存储，主键索引的叶结点存储行数据。对于普通索引

特点 原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability) 一、事务的目的 1、可靠性和并发处理 可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离级别。 二、实现事务功能的三个技术 1、日志文件(redo log 和 undo log) 2、锁技术 3、MVCC 1.1 redo log 与 undo log介绍 1.1.1redo log 什么是redo log ? redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。 当事务提交之后会把所有修改信息都会存到该日志中。假设有个表叫做tb1(id,username) 现在要插入数据（3，ceshi） start transaction; select

事物机制 5.0版本后出现的,解决: 避免写入直接操作数据文件,直接操作数据文件是很危险的事 MySQL有5种日志文件,其中只有redo日志和undo日志与事物有关 RDBMS=SQL语句 + 事务(ACID) 原子性 事务是一个或者多个SQL语句组成的整体,要么全部执行成功,要么全都执行失败 ,事务执行之后,不允许停留在中间某个状态 把10部门中MANGER员工调往20部门,其他岗位员工调往30部门,然后删除10部门 事务: 开启事务 UPDATE语句 DELETE语句 提交事务 默认情况下,MySQL执行每条SQL语句都会自动开启和提交事务 为了让多条SQL语句纳入一个事务下,可以手动管理事务 START TRANSACTION; SQL语句 [COMMIT | ROLLBACK]; COMMIT:持久化提交 ROLLBACK:回滚 START TRANSACTION; -- 启动事务机制 delete from t_emp; delete from t_dept; SELECT * FROM t_emp; SELECT * FROM t_dept; -- COMMIT; -- 提交同步(给注释掉了) ROLLBACK ; -- 回滚不同步 事务的一致性 不管在任何给定的时间\并发事务有多少, 事务必须保证运行结果的一致性,不允许数据歧义 隔离性

JDBC操作数据库的步骤 ？ 注册数据库驱动。 建立数据库连接。 创建一个Statement。 执行SQL语句。 处理结果集。 关闭数据库连接 代码如下 JDBC中的Statement 和PreparedStatement，CallableStatement的区别？ 区别： PreparedStatement是预编译的SQL语句，效率高于Statement。 PreparedStatement支持?操作符，相对于Statement更加灵活。 PreparedStatement可以防止SQL注入，安全性高于Statement。 CallableStatement适用于执行存储过程。 JDBC中大数据量的分页解决方法? 最好的办法是利用sql语句进行分页，这样每次查询出的结果集中就只包含某页的数据内容。 说说数据库连接池工作原理和实现方案？ 工作原理： JAVA EE服务器启动时会建立一定数量的池连接，并一直维持不少于此数目的池连接。客户端程序需要连接时，池驱动程序会返回一个未使用的池连接并将其表记为忙。如果当前没有空闲连接，池驱动程序就新建一定数量的连接，新建连接的数量有配置参数决定。当使用的池连接调用完成后，池驱动程序将此连接表记为空闲，其他调用就可以使用这个连接。 实现方案： 连接池使用集合来进行装载，返回的Connection是原始Connection的代理