隔离级别

01 概述 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。 OLTP 场景下通常要求具有很高的并发性。并发事务实际上取决于资源的使用状况，原则上应尽量减少对资源的锁定时间，减少对资源的锁定范围，从而能够尽量增加并发事务的数量，那么影响并发的因素有哪些呢？本文将从巨杉分布式数据库本身的机制以及隔离级别、数据库锁、参数、及实际例子进行详解，读完本文将对巨杉数据库并发性与锁机制有一个初步的了解。 02 隔离级别与并发性 在单用户环境中，每个事务都是顺序执行的，而不会遇到与其他事务的冲突。但是，在多用户环境下，多个事务并发执行。因此每个事务都有可能与其他正在运行的事务发生冲突。有可能与其他事务发生冲突的事务称为交错的或并行的事务，而相互隔离的事务称为串行化事务，这意味着同时运行它们的结果与一个接一个连续地运行它们的结果没有区别。在多用户环境下，在使用并行事务时，会发生四种现象： 丢失更新：这种情况发生在两个事务读取并尝试更新同一数据时

2.2.1 并发一致性问题 常见并发并发一致性问题包括：丢失的修改、不可重复读、读脏数据、幻影读（幻影读在一些资料中往往与不可重复读归为一类）。 2.2.1.1 丢失修改 下面我们先来看一个例子，说明并发操作带来的数据的不一致性问题。 考虑飞机订票系统中的一个活动序列: 甲售票点（甲事务）读出某航班的机票余额A,设A=16. 乙售票点（乙事务）读出同一航班的机票余额A,也为16. 甲售票点卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库. 乙售票点也卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库. 结果明明卖出两张机票，数据库中机票余额只减少1。 归纳起来就是：两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。前文（2.1.4数据删除与更新）中提到的问题及解决办法往往是针对此类并发问题的。但仍然有几类问题通过上面的方法解决不了，那就是： 2.2.1.2 不可重复读 不可重复读是指事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果。具体地讲，不可重复读包括三种情况： 事务T1读取某一数据后，事务T2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。例如，T1读取B=100进行运算，T2读取同一数据B，对其进行修改后将B=200写回数据库。T1为了对读取值校对重读B，B已为200

Spring声明式事务让我们从复杂的事务处理中得到解脱。使得我们再也无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。再也无需要我们在与事务相关的方法中处理大量的try…catch…finally代码。 我们在使用Spring声明式事务时，有一个非常重要的概念就是事务属性。事务属性通常由事务的传播行为，事务的隔离级别，事务的超时值和事务只读标志组成。我们在进行事务划分时，需要进行事务定义，也就是配置事务的属性。 Spring在 TransactionDefinition 接口中定义这些属性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事务管理的核心接口。 Java代码 TransactionDefinition public interface TransactionDefinition { int getPropagationBehavior(); int getIsolationLevel(); int getTimeout(); boolean isReadOnly(); } getTimeout()方法，它返回事务必须在多少秒内完成。 isReadOnly(),事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的。 getIsolationLevel(

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

事务处理之父Jim Gray对事务隔离性的定义： Isolation: Concurrently executing transactions see the stored information as if they were running serially (one after another). 事务的隔离级别从低到高有： Read Uncommitted ：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。 Read Committed ：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。 Repeated Read ：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。 Serialization ：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。 通常，在工程实践中，为了性能的考虑会对隔离性进行折中。 其中只有serialization实现隔离性所有要求，在真正实现事务的隔离性。 但考虑到实践，为了性能，数据库厂商做出了这方面的妥协，让使用者可以选择隔离的级别。 不同的隔离级别可以解决不同阶段的问题，是层层递进，逐渐增强的关系。 隔离性为了解决的问题主要有三个

网络上关于这方面的博文有些偏理论，有些通篇代码，都不能深入浅出。本文用图文并茂的方式，配上行云流水般的代码，非要摆清楚这个问题。相关代码已提交至码云（点击 这里 下载）。 事务是现代关系型数据库的核心之一。在多个事务并发操作数据库（多线程、网络并发等）的时候，如果没有有效的避免机制，就会出现以下几种问题： 第一类丢失更新（Lost Update） 在完全未隔离事务的情况下，两个事务更新同一条数据资源，某一事务完成，另一事务异常终止，回滚造成第一个完成的更新也同时丢失 。这个问题现代关系型数据库已经不会发生，就不在这里占用篇幅，有兴趣的可以自行百度。 脏读（Dirty Read） A事务执行过程中，B事务读取了A事务的修改。但是由于某些原因，A事务可能没有完成提交，发生RollBack了操作，则B事务所读取的数据就会是不正确的。这个未提交数据就是脏读（Dirty Read）。脏读产生的流程如下： 可以用EF Core模拟此过程： class TestReadUncommitted :TestBase { private AutoResetEvent _autoResetEvent; [Test] public void ReadUncommitted() { using (var context = _autofacServiceProvider.GetService

关系型数据库都具有一套事务级别，以前的开发和学习过程我很少关注过这个概念，今天搜集了一些资料，在 结合spring声明式事务学习的同时，总结一下数据库的事务级别与操作。 READ-UNCOMMITTED: 未提交读 会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 ) READ-COMMITTED: 提交读 会出现不可重复读、幻读问题（锁定正在读取的行） REPEATABLE-READ: 可重复读 会出幻读（锁定所读取的所有行） SERIALIZABLE: 序列化 保证所有的情况不会发生（锁表） 详细说明： 未提交读 ——这通常称为 'dirty read'：non-locking SELECT 的执行使我们不会看到一个记录的可能更早的版本； 因而在这个隔离级别下是非 'consistent' reads；这级隔离级别的运作如同 READ COMMITTED。处于这个隔离级的 事务可以读到其他事务还没有提交的数据。如果这个事务使用其他事务未提交的变化作为计算的基础，然后那些未 提交的变化被他们的父事务撤销，则会导致误差。 提交读 ——在一个事务中已经COMMIT的数据可以在其他事务中看到。如果这个事务频繁提交的话，其他的大的查询 事务中可能会得到多个不同的结果。 可重复读 ——这是 InnoDB 默认的事务隔离级。在一个事务中所有读都是连续的。 序列化 —

一、事务隔离级别 　　在数据库系统中， 隔离 是定义一个操作对数据所做的改变如何/何时对其它的 并行 操作可见。　　 　　在数据库操作中， 为了有效保证并发读取数据的正确性 ，提出的事务隔离级别。 　　事务隔离级别：一个事务对数据库的修改与并行的另一个事务的隔离程度。　　 二、事务并发执行涉及到的问题 　　数据库是要被广大客户所共享访问的，那么在数据库操作过程中很可能出现以下几种不确定情况： 　　脏读(Drity Read)：某个事务已更新一份数据还未提交，另一个事务在此时读取了同一份数据，由于某些原因，前一个事务RollBack了操作，则后一个事务所读取到的数据就会是不正确的。 　　不可重复读(Non-repeatable read):在一个事务的两次相同查询中数据不一致，这可能是两次查询过程中间插入了另一个事务更新了原有的数据。也可以说：事务T1读取某一数据后还未提交，事务T2对其做了修改，当事务T1再次读该数据时得到与前一次不同的值。 　　幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。 三、解决方法--4类事务隔离级别 　　SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的

隔离性 mysql提供了4种不同的隔离级别以支持多版本并发控制(MVCC) 较低级别的隔离通常可以执行更高的并发,系统的开销也更低 read uncommited(未提交读) read commited(提交读) repeatable read(可重复读) serializable(可串行化) 默认repeatable-read 建议最好不要修改默认的隔离级别,修改隔离级别会对mysql复制产生影响 isolation-table.sql DROP TABLE IF EXISTS transaction_test; CREATE TABLE transaction_test( id INT UNSIGNED NOT NULL AUTO_INCREMENT, val VARCHAR(20) NOT NULL, created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY(id) ) ENGINE=InnoDB DEFAULT CHARSET latin1; #初始化数据 insert into transaction_test(val) values ('a'),('b'),('c'); 1.REPEATABLE-READ(可重复读) 解决了脏读问题.该级别保证了在同一事物中多次读取同样的记录结果是一样的