事务隔离级别

事务是一个工作单元，可能包含查询和修改数据以及修改数据定义等多个活动。我们可以显式或隐式的定义事务边界。可以使用BEGIN TRAN或者BEGIN TRANSACTION语句显式的定义事务的开始。如果希望提交事务，可以使用COMMIT TRAN语句显式的定义事务结束。如果不希望提交事务（即要撤销更改），可以使用ROLLBACK TRAN或者ROLLBACK TRANSACTION语句-摘抄自SQL Server 2012基础教程。 如果不显式的标记事务的边界，默认情况下，SQL Server将把每个单独语句作为一个事务，换句话说，默认情况下，每个单独语句结束后SQL Server自动提交事务。 说到事务就联想到并发，为了解决事务中的并发我们则不得不讨论下锁，所以接下来我们首先熟悉一下锁的模式-排他锁和共享锁。 先看看下面的试验，先开始一个事务处理，这个事务不提交也不回滚，然后另外在打开一个窗口查询数据。 在上面的事务没有提交也没有回滚的情况下，如果另一个程序在执行查询，那么就会阻塞，如果没有设置查询超时，就会一直等待。 原因：当事务会话对表进行修改（增删改）时，事务会请求数据资源的一个排他锁，这个锁直到事务完成（提交或者回滚）才会被取消。当读取数据时需要获取该资源上的共享锁，但是排他锁和共享锁不能兼容，此时会导致查询阻塞不得不进行等待。 就上面的试验，第一个事务拥有排它锁

一、什么是事务 　　事务是访问数据库的一个操作序列，数据库应用系统通过事务集来完成对数据库的存取。事务的正确执行使得数据库从一种状态转换成另一种状态。 　　事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性（atomicity）、 一致性（consistency）、隔离性（isolation）和持久性（durability）的缩写事务必须服从ISO/IEC所制定的ACID原 则。ACID是原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）的缩 写。 原子性 。即不可分割性，事务要么全部被执行，要么就全部不被执行。如果事务的所有子事务全部提交成功，则所有的数据库操作被提交，数据库状态发生转换；如果有子事务失败，则其他子事务的数据库操作被回滚，即数据库回到事务执行前的状态，不会发生状态转换。 一致性或可串性 。事务的执行使得数据库从一种正确状态转换成另一种正确状态。 隔离性 。在事务正确提交之前，不允许把该事务对数据的任何改变提供给任何其他事务，即在事务正确提交之前，它可能的结果不应显示给任何其他事务。 持久性 。事务正确提交后，其结果将永久保存在数据库中，即使在事务提交后有了其他故障，事务的处理结果也会得到保存。 　　 　　运行嵌入式SQL应用程序或脚本，在可执行SQL语句第一次执行时

来源参考文章: https://blog.csdn.net/wohaqiyi/article/details/72895983 http://www.cnblogs.com/xusir/p/3650522.html 要点: 1、需要的注解为 @EnableTra nsactionManagement 和 @Transactional 两个，它们来自于下边这个包：(一般只要配好srping-boot-mybaits就有) spring-tx.jar 关于@ EnableTra nsactionManagement 如下 @SpringBootApplication @EnableTransactionManagement //如果mybatis中service实现类中加入事务注解，需要此处添加该注解 @MapperScan("cloud.kafka.mapper") //扫描的是mapper.xml中namespace指向值的包位置 public class KafkaLogApplication { public static void main(String[] args){ SpringApplication.run(KafkaLogApplication.class, args); } } 关于@ Transactional 如下 spring事务特性

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 隔离级别为四种分别解决脏读，不可重复度，幻读等问题 脏读：指一个线程中的事务读取到了另外一个线程中未提交的数据。 不可重复读：一个事务对同一行数据重复读取两次，但是却得到了不同的结果。例如，在两次读取的中途，有另外一个事务对该型数据进行了修改，并提交。 幻读：一个线程事务读取到相关数据就一条，第二次读出现两条，新增的一条为另外一个线程事务提交插入的数据。 上图为各个隔离级别对应的问题 show variables like '%iso%'; 查看目前数据库的隔离级别 set @@session.tx_isolation = 'READ-COMMITTED'; --设置局部 set @@session.tx_isolation = 'REPEATABLE-READ'; 局 @@session 全 @@global 级联回滚(5.7.22后不会发生) 事务是需要手动提交和回滚的 来源： oschina 链接： https://my.oschina.net/u/3914215/blog/3145394

1、模型 2、解耦 3、实现 3.1 核心接口 3.2 代码分析 3.2.1 事务管理 3.2.2 数据访问 4、使用 4.1 编程模式 4.2 配置模式 4.2.1 声明式配置方式 4.2.2 注解式配置方式 5、总结 1、模型 在一般的编程习惯中，Spring的数据访问和事务处理的层次结构归纳如下图所示： 图. 1 2、解耦 Spring事务作为一个独立的组件，其目的就是为了与数据访问组件进行分离，这也是Spring事务框架设计的原则。根据这一职责清晰的原则，Spring在设计时就对事务和数据访问进行了很好的职责划分，这个可以从spring-tx和spring-jdbc这两个包就可以看出来。 但是在实际的代码中，会遇到一个棘手的问题：事务和数据访问操作都需要同一个数据库连接资源，那么它们之间怎么传递呢？ 这里涉及三个方面：一是线程安全，二是资源的唯一性，三是事务和数据访问的解耦。 图. 2 在图2中的1、2和3这三个地方都需要使用数据库连接，并且是同一个连接。Spring的做法是将该连接放在一个统一的地方，要使用该资源，都从这个地方获取，这样就解决了事务模块和数据访问模块之间的紧耦合。 解除耦合之后，对于不同的ORM技术，则需要提供不同的事务管理实现，如下图所示： 图. 3 3、实现 3.1 核心接口 Spring事务框架的核心接口是：TransactionDefinition

Auth: jin Date: 20140507 一、事务控制 默认情况下，MySQL是自动提交(autocommit)的，如果需要通过明确的commit和rollblack来提交和回滚事务，那么需要通过明确的事务控制命令来开始事务。 SET AUTOCOMMIT, START TRANSACTION,COMMIT和ROLLBACK等语句支持本地事务。 1、开始一个项新的事务 START TRANSACTION 或BEGIN语句可以开始一项新的事务。 2、提交回滚事务 COMMIT和ROLLBACK用来提交回滚事务 3、在事务提交或回滚之后的操作 CHAIN和RELEASE 字句分别用来定义在事务提交或回滚之后的操作。 CHAIN会立即开启一个新事务，并且和刚才的事务具有相同的隔离级别 RELEASE 会断开和客户端的链接。 4、修改当前的链接的提交方式 SET AUTOCOMMIT 可以修改当前的链接的提交方式,如果设置了SET AUTOCOMMIT=0, 则设置之后的所用事务都需要通过明确的命令提交或回滚。 实例 CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(25) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`)

测试 READ UNCOMMITTED(读取未提交）的隔离性； insert into user values ( 3 , '小明' , 1000 ) ; insert into user values ( 4 , '淘宝店' , 1000 ) ; select * from user ; + ----+-----------+-------+ | id | name | money | + ----+-----------+-------+ | 1 | a | 900 | | 2 | b | 1100 | | 3 | 小明 | 1000 | | 4 | 淘宝店 | 1000 | + ----+-----------+-------+ 开启一个事务操作数据 小明在淘宝店买了一个 100 元的零食 star transaction ; update user set money = money - 100 where name = '小明' ; update user set money = money + 100 where name = '淘宝店' ; 淘宝店查询结果 select * from user ; SELECT * FROM user ; + ----+-----------+-------+ | id | name | money | + ----+--------

Transaction 也就是所谓的事务了，通俗理解就是一件事情。从小，父母就教育我们，做事情要有始有终，不能半途而废。 事务也是这样，不能做一半就不做了，要么做完，要么就不做。也就是说，事务必须是一个不可分割的整体，就像我们在化学课里学到的原子，原子是构成物质的最小单位。于是，人们就归纳出事务的第一个特性：原子性（Atomicity）。我靠，一点都不神秘嘛。 特别是在数据库领域，事务是一个非常重要的概念，除了原子性以外，它还有一个极其重要的特性，那就是：一致性（Consistency）。也就是说，执行完数据库操作后，数据不会被破坏。打个比方，如果从 A 账户转账到 B 账户，不可能因为 A 账户扣了钱，而 B 账户没有加钱吧。如果出现了这类事情，您一定会非常气愤，什么 diao 银行啊！ 当我们编写了一条 update 语句，提交到数据库的一刹那间，有可能别人也提交了一条 delete 语句到数据库中。也许我们都是对同一条记录进行操作，可以想象，如果不稍加控制，就会出大麻烦来。我们必须保证数据库操作之间是“隔离”的（线程之间有时也要做到隔离），彼此之间没有任何干扰。这就是：隔离性（Isolation）。要想真正的做到操作之间完全没有任何干扰是很难的，于是乎，每天上班打酱油的数据库专家们，开始动脑筋了，“我们要制定一个规范，让各个数据库厂商都支持我们的规范！”，这个规范就是

https://dev.mysql.com/doc/refman/5.7/en/innodb-deadlocks.html 什么是mysql的死锁？ A deadlock is a situation where different transactions are unable to proceed because each holds a lock that the other needs. Because both transactions are waiting for a resource to become available, neither ever release the locks it holds. 简单来说可以提炼出2个词：环路等待（ each holds a lock that the other needs ）和不可剥夺（ neither ever release the locks it holds ）。 其实广泛意义上死锁的四个必要条件也可以直接简化为上述两个条件，剩下的互斥和请求保持条件只是两个众所周知的补充。 一、一个简单的死锁示例： 会话A： mysql> CREATE TABLE t (i INT) ENGINE = InnoDB; Query OK, 0 rows affected (1.07 sec) mysql> INSERT INTO

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 导读 我们知道可以在线修改全局或会话级的事务隔离级别，也可以修改时不指定GLOBAL/SESSION关键字，而只影响当前会话中的下一个事物，但怎么确认修改生效了呢？ 我们知道，可以分别用 @@global.transaction_isolation 和 @@ session.transaction_isolation来查看全局或会话级隔离级别，或者用 @@transaction_isolation 查看会话级隔离级别。也就是说： @@session.transaction_isolation 和 @@transaction_isolation 二者等价。 在MySQL里，可以在线修改全局或会话级的事务隔离级别，例如这样： 可以看到全局和会话级的隔离级别是不一样的 另外，我们也知道，在修改隔离级别时若不指定 GLOBAL/SESSION 关键字，则只会针对当前会话的下一个事务生效，下一个事务结束后，又会恢复当前会话此前设定的隔离级别。 但可能有些同学不太放心，或者可能就想确认某个事务的隔离级别。接下来，我们一起来看下，怎么查看确认某个事务的隔离级别。 这种情况下，我们就需要借助 information_schema.innodb_trx这个视图了，看下面例子。 最后几点结论： 1、执行 select @@tx