隔离级别

一.问题 1.脏读 已知有 两个事 务 A 和 B, A读取了已经被B更新但还没有被提交的 数据， 之后 ， B回滚 事务， A读取的 数据就是脏数据 场景：公司发工资了，领导把5000元打到Tom的账号上，但是该事务并未提交，而Tom正好去查看账户，发现工资已经到账，账户多了5000元，非常高兴，可是不幸的是，领导发现发给Tom的工资金额不对，是2000元，于是迅速回滚了事务，修改金额后，将事务提交，Tom再次查看账户时发现账户只多了2000元，Tom空欢喜一场，从此郁郁寡欢，走上了不归路…... 分析：上述情况即为脏读，两个并发的事务：“事务B：领导给Tom发工资”、“事务A：Tom查询工资账户”，事务A读取了事务B尚未提交的数据 2.不可重复读 已知有 两个事 务 A 和 B ，A 多次读取同一数据，B 在A多次读取的过程中对数据作了 修改 并提交，导致A多次读取同一数据时，结果不一致，例子： 场景：Tom拿着工资卡去消费，酒足饭饱后在收银台买单，服务员告诉他本次消费 1 000 元 ，Tom将银行卡给服务员，服务员将银行卡插入POS机，POS机读到卡里余额为 3000元 ，就在Tom磨磨蹭蹭输入密码时，他老婆以迅雷不及掩耳盗铃之势把Tom工资卡的 3 000元 转到自己账户并提交了事务，当Tom输完密码并点击“确认”按钮后，POS机检查到Tom的工资卡已经没有钱，扣款失败

事务隔离级别 同一个应用程序中的多个事务或不同应用程序中的多个事务在同一个数据集上 并发 执行时 , 可能会出现许多意外的问题，这些问题可分为如下三种类型： 脏读 (Drity Read) : 已知有两个事务 A 和 B, A 读取了已经被 B 更新但还没有被提交的数据，之后， B 回滚事务， A 读取的数据就是脏数据。 场景：公司发工资了，领导把5000元打到Tom的账号上，但是该事务并未提交，而Tom正好去查看账户，发现工资已经到账，账户多了5000元，非常高兴，可是不幸的是，领导发现发给Tom的工资金额不对，是2000元，于是迅速回滚了事务，修改金额后，将事务提交，Tom再次查看账户时发现账户只多了2000元，Tom空欢喜一场，从此郁郁寡欢，走上了不归路…... 分析：上述情况即为脏读，两个并发的事务：“事务B：领导给Tom发工资”、“事务A：Tom查询工资账户”，事务A读取了事务B尚未提交的数据。 不可 重复 读 (Non-repeatable read) : 已知有两个事务 A 和 B ， A 多次读取同一数据， B 在 A 多次读取的过程中对数据作了 修改 并提交，导致 A 多次读取同一数据时，结果不一致，例子： 场景：Tom拿着工资卡去消费，酒足饭饱后在收银台买单，服务员告诉他本次消费 1000 元 ，Tom将银行卡给服务员，服务员将银行卡插入POS机

一、在多事务在在相近的时间由多人处理时，此时往往存在一系列并发问题： 1、 脏读（Drity Read） 已知有两个事务 A 和 B, A 读取了已经被 B 更新但还没有被提交的数据，之后， B 回滚事务， A 读取的数据就是脏数据 2、 不可重复读（Non-repeatable read） 已知有两个事务A 和 B ， A 多次读取同一数据， B 在 A 多次读取的过程中对数据作了 修改 并提交，导致 A 多次读取同一数据时，结果不一致 3、 幻读（Phantom Read） 已知有两个事务A 和 B ， A 从一个表中读取了数据，然后 B 在该表中 插入 了一些新数据，导致 A 再次读取同一个表 , 就会多出几行，简单地说，一个事务中先后读取一个范围的记录，但每次读取的纪录数不同，称之为幻象读 注：不可重复读与幻读 区别就是在读取数据是另一方对数据尽行了何种修改： 修改 和 插入 二、处理方法： 事务隔离权限 根据实际需求，通过设置数据库的事务隔离级别可以解决多个事务并发情况下出现的脏读、不可重复读和幻读问题，数据库事务隔离级别由低到高依次为 Read uncommitted、Read committed、Repeatable read和Serializable 等四种。数据库不同，其支持的事务隔离级别亦不相同： MySQL数据库支持上面四种事务隔离级别

事务的提交模式（事务的持久特性）： 1、自动提交模式（一条sql语句就是一个事务 ） 2、显示提交模式（要求程序员显示添加begin tran和commit tran/rollback tran，中间添加任意多sql语句） 3、隐式提交模式（begin tran是由dbms发的，commit tran/rollback tran是由程序员显示添加，中间可以添加任意多sql语句，也就是说commit tran/rollback tran的下一句就是一个新事务的开始） 注：在ADO.NET中仅支持自动提交模式（默认模式）和显示提交模式） 在编程中需要考虑的并发冲突有： 1、脏读：读取未提交的数据。一个进程更新了数据但在另一个进程读取相同数据之前未提交该更新。第二个进程所读取的数据处于一种不一致状态。 图1-0（t3时刻事务T2读到了脏数据） 2、丢失修改：一个进程读取了数据，并对数据执行了一些计算，然后根据这些计算更新数据。如果两个进程都是先读取数据，然后再根据他们所读取数据更新，其中一个进程可能会覆盖另一个进程的更新。 图1-1（本身卖完两张票后数据库中A应为0，丢失修改造成A为1） 3、不可重复读：在同一事物的两次读取中，进程读取相同的资源得到不同的值。当第二个进程在第一个进程的两次读取之间更新数据，就会发生这种情况。 图1-2（两次读取不一致数据） 4、幻读

1.学习链接: https://www.cnblogs.com/xd502djj/p/10940627.htmlhttps://www.cnblogs.com/caoyc/p/5632963.htmhttps://www.cnblogs.com/chengshun/p/9778880.html 2.事物场景: https://blog.csdn.net/kiwi_coder/article/details/20214939 3.参数: 4.注意的几点: 　　1、@Transactional 只能被应用到public方法上, 对于其它非public的方法,如果标记了@Transactional也不会报错,但方法没有事务功能. 　　2、用 spring 事务管理器,由spring来负责数据库的打开,提交,回滚.默认遇到运行期例外(throw new RuntimeException("注释");)会回滚，即遇到不受检查（unchecked）的例外时回滚；而遇到需要捕获的例外(throw new Exception("注释");)不会回滚,即遇到受检查的例外（就是非运行时抛出的异常，编译器会检查到的异常叫受检查例外或说受检查异常）时，需我们指定方式来让事务回滚要想所有异常都回滚,要加上 @Transactional( rollbackFor={Exception.class,其它异常})

事务的隔离级别 事务的隔离级别源于事务ACID的I（Isolation），即多个事务同时操作同一实体时，其中一个事务的读写操作对其他事务及其自身的可见性影响程度。具体可以分为如下几个等级： 读未提交 某个事务未提交前，其修改的数据对其他事务可见，这种隔离级别最低，除了确保执行事务本身的原子性，对其他事务几乎无隔离，所以如果源事务回滚，其他事务就会出现脏读现象。 读已提交 一个事务针对数据的写操作，只有提交之后，其他事务才可见。这是相对靠谱的方案。也是很多数据库的默认隔离级别。读提交也存在两个主要的问题，第一种是，如果两个事务同时开启，其中一个事务第一次读取，和在另一个事务修改并提交后读取到的数据会不一致，也就是不可重复读；第二个问题是，容易引起死锁。 可重复读 一个事务针对数据的读操作一旦开始，其他事务不再可以进行写操作，相当于读锁。可重复读增加了数据的安全性，但是针对新增操作，依然存在幻读问题。 串行化 串行化是安全性最高的一种隔离界别，也是用的最少的一种隔离级别，事务串行化执行，吞吐量严重受限。 事务的传播级别 和事务的隔离级别不同，传播特性是指一个事务开启后，如果在事务内涉及到其他事务的调用，是沿用主事务，还是开启新事务，亦或是，不接受事务。 REQUIRED 如果存在一个事务，支持当前事务。如果没有则开启一个新的事务。 SUPPORTS 如果存在一个事务，支持当前事务

数据库隔离级别 目的： 保证事务并发读取数据的正确性 数据库事务隔离级别 （1） Read uncommitted（读未提交数据）： 允许事务读取未被其他事务提交的变更数据，会出现脏读、不可重复读和虚读。 （2） Read committed（读已提交数据）： 只允许事务读取已经被其他事务提交的变更数据，可避免脏读，仍会有不可重复读和虚读 （3） Repeatable read（可重复读）： 确保事务可以多次从一个字段中读取相同的值，在此事务持续期间，禁止其他事务对此字段的更新，可避免脏读、不可重复读仍会有虚读。 （4） Serializable（序列化）： 确保事务可以从一个表中读取相同的行，在事务持续期间，禁止其他事务对该表执行插入、更新和删除操作，可避免所有并发问题，但性能低。 MySQL支持四种事务隔离级别，其中REPEATABLE READ为默认事务隔离级别。 设置说明： 隔离级别越高，越能保证数据的完整性和一致性，但对并发性的影响越大。对于大多数应用程序，数据库系统的隔离级别设为ReadCommitted。能避免脏读取，而且具有较好的并发性能。对于不可重复读、虚读和第二类丢失更新这些并发问题，采用悲观锁或乐观锁。 悲观锁和乐观锁 悲观锁：每次拿数据时怕别人会修改，所以都会先上锁，当其他事务要访问该数据时就会阻塞。一般用在表锁、行锁、读锁和写锁，在操作前先上锁。 乐观锁

事务： 当然有的人用begin /begin work .推荐用START TRANSACTION 是SQL-99标准启动一个事务。 start transaction #开始一个事务 操作 savepoint sp1 #保存点名称 操作 ROLLBACK ROLLBACK To sp1 #回退到 sp1点 commit 当用set autocommit = 0 的时候，你以后所有的sql都将作为事务处理，直到你用commit确认或 rollback结束，注意当你结束这个事务的同时也开启了新的事务！mysql 默认 autocommit=1，是自动提交的。 隔离级别 SQL标准定义的四个隔离级别为： 1.读未提交（Read Uncommitted）：在READ COMMITED的事务隔离级别下，除了唯一性的约束检查以及外键约束的检查需要Gap Lock，InnoDB存储引擎不会使用Gap Lock的锁算法。这种隔离级别可以让当前事务读取到其它事物还没有提交的数据。这种读取应该是在回滚段中完成的。通过上面的分析，这种隔离级别是最低的，会导致引发脏读，不可重复读，和幻读。 2.读已提交（Read Committed）：这种隔离级别可以让当前事务读取到其它事物已经提交的数据。通过上面的分析，这种隔离级别会导致引发不可重复读，和幻读。 3.可重复读取（Repeatable Read）

什么是事务 事务是访问数据库的一个操作序列，数据库应用系统通过事务集来完成对数据库的存取。 事务的正确执行使得数据库从一种状态转换为另一种状态 。 事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability）的缩写，这四种状态的意思是： 1、原子性 即不可分割，事务要么全部被执行，要么全部不执行。如果事务的所有子事务全部提交成功，则所有的数据库操作被提交，数据库状态发生变化；如果有子事务失败，则其他子事务的数据库操作被回滚，即数据库回到事务执行前的状态，不会发生状态转换 2、一致性 事务的执行使得数据库从一种正确状态转换成另外一种正确状态 3、隔离性 在事务正确提交之前，不允许把事务对该数据的改变提供给任何其他事务，即在事务正确提交之前，它可能的结果不应该显示给其他事务 4、持久性 事务正确提交之后，其结果将永远保存在数据库之中，即使在事务提交之后有了其他故障，事务的处理结果也会得到保存 事务的作用 事务管理对于企业级应用而言至关重要，它保证了用户的每一次操作都是可靠的，即便出现了异常的访问情况，也不至于破坏后台数据的完整性。就像银行的自动提款机ATM，通常ATM都可以正常为客户服务，但是也难免遇到操作过程中及其突然出故障的情况，此时

1.RR隔离级别：在此隔离级别下， DB2会锁住所有相关的纪录。在一个SQL语句执行期间，所有执行此语句扫描过的纪录都会被加上相应的锁。具体的锁的类型还是由操作的类型来决定，如果是读取，则加共享锁；如果是更新，则加独占锁。由於会锁定所有為获得SQL语句的结果而扫描的纪录，所以锁的数量可能会很庞大，这个时候，索引的增加可能会对SQL语句的执行有很大的影响，因為索引会影响SQL语句扫描的纪录数量。 2.RS隔离级别：此隔离级别的要求比RR隔离级别稍弱，此隔离级别下会锁定所有符合条件的纪录。不论是读取，还是更新，如果SQL语句中包含查询条件，则会对所有符合条件的纪录加相应的锁。 如果没有条件语句， 也就是对表中的所有记录进行处理，则会对所有的纪录加锁。 3.CS隔离级别：此隔离级别仅锁住当前处理的纪录。 4.UR隔离级别：此隔离级别下，如果是读取操作，不会出现任何的行级锁。 对于非只读的操作，它的锁处理和CS相同。 DB2默认的隔离级别是CS。 DB2默认的隔离级别是CS。 即游标稳定性。即游标稳定性。 详细说明： 当多个用户访问同一数据库时会发生的现象介绍如下： 在单用户环境中，每个事务都是顺序执行的，而不会遇到与其他事务的冲突。但是，在多用户环境下，多个事务可以（而且常常）同时执行。因此每个事务都有可能与其他正在运行的事务发生冲突。有可能与其他事务发生冲突的事务称为交错的 或并行的