隔离级别

目的 在数据库操作中，为了有效保证并发读取数据的正确性，提出的事务隔离级别。我们的数据库锁，也是为了构建这些隔离级别存在的。 分类 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读) 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞 锁 表锁: 对整张表加锁,分为读锁和写锁.因为会锁住整张表,所以一般只在执行DDL之前使用 行锁:事务就是通过行锁来实现的. 在RC级别,数据的读取都是不加锁的，但是数据的写入、修改和删除是需要加锁的。 RR级别(MySQL的默认级别)中,分为读和写两种场景: 读: 同一事务的多个实例在并发读取数据时，会看到同样的数据行(不管此时是否有其他事务修改了数据且提交).MySQL通过MVCC(创建版本号+删除版本号)来实现可重复读. 写:使用Next-Key锁(行锁 + GAP 间隙锁) Serializable : 读加共享锁，写加排他锁，读写互斥

1.事务的并发问题 脏读 ：事务A读取了事务B更新的数据,然后B进行了回滚操作，这时A读到的数据就是脏数据，侧重于一个事务读取了另一个未提交事务修改的数据。 不可重复读 ：事务A多次读取同一数据，事务B在事务A多次读取的过程中，对数据作了更新并提交(和脏读不一样的地方)，导致事务A多次读取同一数据时，结果不一致。 幻读 ：系统管理员A将数据库中所有学生的成绩从具体分数改未ABCD，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条计数没有改过来，就好像发生了幻觉一样，这就叫幻读。 小结：脏读侧重于一个事务读取了另一个未提交事务操作的数据，不可重复读侧重于一个事务读取到了另一个已提交事务修改的数据，幻读侧重于一个事务读取到了另一个已提交事务新增或删除的数据。 2.事务隔离级别概述 mysql中，innodb所提供的事务符合ACID的要求，而事务通过事务日志中的redo log和undo log满足了原子性、一致性、持久性，事务还会通过锁机制满足隔离性，在innodb存储引擎中，有不同的隔离级别，它们有着不同的隔离性，一共有如下4中： READ-UNCOMMITED ：读未提交 READ-COMMITED ：读已提交，解决了脏读问题 REPEATABLE-READ ：可重复读，默认，解决了脏读和不可重复读问题 SERIALIZABLE ：串行化

提到事务，你肯定会想到ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性），今天我们就来说说其中I，也就是“隔离性”。 数据库上有多种事务同时执行的话，可能出现脏读，不可重复读，幻读. 幻读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，比如这种修改涉及到表中的“全部数据行”。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入“一行新数据”。那么，以后就会发生操作第一个事务的用户发现表中还存在没有修改的数据行，就好象发生了幻觉一样. 一般解决幻读的方法是增加范围锁RangeS，锁定检索范围为只读，这样就避免了幻读。 SQL标准的事务隔离级别包括：读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）。 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。 可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。 串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”

如何理解多租户架构？ 引用： https://www.cnblogs.com/pingfan21/p/7478242.html 　　 前段时间公司产品进行了架构的进化，进化到了多租户架构。当我第一次听到多租户时，我也挺纳闷，不理解。但当我逐渐的翻阅资料，以及研发功能时。不断的加深了对多租户的理解。尽管我现在也只是浅浅的懂一点而已。 　　OK,Let's get this straight（让我们搞懂它），接下来让我们问自己几个问题: 　　1.什么是多租户架构？ 　　2.多租户架构的优缺点？ 　　3.多租户架构的适用场景？ 　　让我们带着这几个问题进入下面的阅读。 一、对多租户的理解 　　多租户定义：多租户技术或称多重租赁技术，简称SaaS，是 一种软件架构技术 ，是实现如何在 多用户环境下（此处的多用户一般是面向企业用户）共用相同的系统或程序组件 ，并且可 确保各用户间数据的隔离性 。简单讲：在一台服务器上运行单个应用实例，它为多个租户（客户）提供服务。从定义中我们可以理解：多租户是一种架构，目的是为了让多用户环境下使用同一套程序，且保证用户间数据隔离。那么重点就很浅显易懂了， 多租户的重点就是同一套程序下实现多用户数据的隔离 。对于实现方式，我们下面会讨论到。 　　在了解详细一点：在一个多租户的结构下，应用都是运行在同样的或者是一组服务器下，这种结构被称为“单实例”架构

前言: 我们都知道事务的几种性质，数据库为了维护这些性质，尤其是一致性和隔离性，一般使用加锁这种方式。同时数据库又是个高并发的应用，同一时间会有大量的并发访问，如果加锁过度，会极大的降低并发处理能力。所以对于加锁的处理，可以说就是数据库对于事务处理的精髓所在。这里通过分析MySQL中InnoDB引擎的加锁机制，来抛砖引玉，让读者更好的理解，在事务处理中数据库到底做了什么。 #一次封锁or两段锁？ 因为有大量的并发访问，为了预防死锁，一般应用中推荐使用一次封锁法，就是在方法的开始阶段，已经预先知道会用到哪些数据，然后全部锁住，在方法运行之后，再全部解锁。这种方式可以有效的避免循环死锁，但在数据库中却不适用，因为在事务开始阶段，数据库并不知道会用到哪些数据。 数据库遵循的是两段锁协议，将事务分成两个阶段，加锁阶段和解锁阶段（所以叫两段锁） 加锁阶段：在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁（共享锁，其它事务可以继续加共享锁，但不能加排它锁），在进行写操作之前要申请并获得X锁（排它锁，其它事务不能再获得任何锁）。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。 解锁阶段：当事务释放了一个封锁以后，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。 事务 加锁/解锁处理 begin； insert into test .....

一、事务的概念 ：事务是由一条或者是多条对数据库操作的SQL语句组成的一个不可分割的单元，只有当事务中的所有的操作都正常成功执行时，整个事务才提交给数据库。 注意：1.事务是一组SQL语句的执行，要么全部执行成功，要么全部执行失败，不能出现部分成功和失败，以保证原子操作 。 2、事务中所有的数据执行成功，才能提交（commit）事务，把结果写入磁盘。 3、事务在执行过程中，有SQL出现了错误，事务必须回滚（rollback）到最初的状态。 二、事务的作用 事务管理对于企业级应用而言至关重要，它保证了用户的每一次操作都是可靠的，即便出现了异常的访问情况，也不至于破坏后台数据的完整性。就像银行的自动提款机ATM，通常ATM都可以正常为客户服务，但是也难免遇到操作过程中及其突然出故障的情况，此时，事务就必须确保出故障前对账户的操作不生效，就像用户刚才完全没有使用过ATM机一样，以保证用户和银行的利益都不受损失。 三、 事务的ACID特征：（4个） 1、原子性（atomic） 事务是一个不可分割的整体，必须具有原子特性，即不可分割，事务要么全部被执行，要么全部不执行。如果事务的所有子事务全部提交成功，则所有的数据库操作被提交，数据库状态发生变化；如果有子事务失败，则其他子事务的数据库操作被回滚，即数据库回到事务执行前的状态，不会发生状态转换 2、一致性（consistency）

https://blog.csdn.net/qq_21359547/article/details/88824901 文章目录： 什么是事务 事务的ACID Mysql四种隔离级别 测试Mysql隔离级别 隔离级别原理分析 一、什么是事务 事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。 事务的结束有两种，当事务中的所以步骤全部成功执行时，事务提交。如果其中一个步骤失败，将发生回滚操作，撤消撤消之前到事务开始时的所以操作。 二、事务的 ACID 事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability ）。这四个特性简称为 ACID 特性。 原子性。事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做 一致性。事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。 隔离性

写在前面: 这个博客记录的是自己学习过程和理解,有些细节可能写的不见得准确,想了解概念,谷歌可以搜出很多不错的博文去学习.我把它记下来,则是为了记录学习的过程,因为有些知识是需要自己创造实践的机会才能真正理解其中的细节. 先贴概念 由ANSI/ISO定义的SQL-92标准定义的四种隔离级别 读取未提交内容/脏读（READ UNCOMMITTED/Dirty Read）：无效数据的读出 . SELECT语句是在无锁的模式下运行，一个事务可以读到另外一个事务的未提交的数据。 提交读（READ COMMITTED）：一个事务不能读到另外一个事务未提交的数据。在这种隔离级别下，对于更新语句来说（SELECT FOR UPDATE,UPDATE和DELETE）, Innodb只会对where条件中索引能覆盖到的行进行上锁 ， 不会上gap锁和next key lock ，所以就 避免不了不可重复读和幻读 。 可重复读（REPEATABLE READ）：是Innodb默认的隔离级别。它使用了 gap locks 或者 next-key locks 来 避免不可重复读的现象，但是仍然避免不了幻读 。如果SELECT FOR UPDATE,UPDATE以及DELETE的where条件能用到唯一索引，INNODB只会对唯一索引能覆盖到的行上行锁；否则就上gap locks或者Next-key

由于数据存储期间，可能发生错误、故障的点特别多，比如网络中断、磁盘写满等，面对这些复杂的情况，应用层应付起来非常困难。所以就有了事务的概念，说道事务，我们最先能想到的就是：可以一次事务中将很多读写入操作打包成一个逻辑操作单元，整个事务不成功（Committed）便成仁（Rollback）。如果失败，应用层可根据情况安全地重试，不用担心部分写入的问题。 总的来说，事务就是一层抽象，为简化应用层编程模型而生！当然，并非所有的数据库都支持事务，但是对关系型数据库而言，这个基本是标配；某些 NoSQL 数据库可能因为性能、可用性以及扩展性考虑，而放弃了对事务的支持。另外，分布式数据库下，事务的实现会更加困难，并且执行开销也很大，但并不代表它不能实现。典型的 分布式关系数据库如 TiDB 以及 Google Spanner 就提供了事务支持。 深入理解 ACID Atomicity（原子性） ：将多个写操作纳入一个原子事务中，并在故障（进程崩溃、网络中断、磁盘故障）发生时能够及时中止事务，并将部分完成的写入全部丢弃。 Consistency（一致性） ： 对数据有特定的状态预期，任何数据变更必须满足这些状态约束（或者恒等条件） 应用进程应该负责保证这种一致性，数据库只是存储 这个更多的是应用层属性 ，所以 C 原本不属于 ACID，只是作者 Joe Hellerstein

所谓隔离性实际上就意味着数据库如何处理并发操作的问题，当两个或者多个操作（或事务）操作同一个数据时，可能引起访问的冲突和数据库的不一致。例如，一个线程需要读取数据库中的某条记录，而另一条线程却要对该条记录进行更新，这就需要通过隔离级的设置来告诉数据库如何处理各种冲突情况。 根据JDBC规范的定义，事务的隔离设置一共分为5种级别，这5种级别的详细规定则依赖于具体使用的数据库。因此在实际应用中还需要查阅底层数据库和JDBC驱动程序的相关文档。下面是对这5种隔离级别（Connection 接口中定义了这5 种隔离级别常量）的简单介绍。 TRANSACTION_NONE:对事务和数据不进行任何隔离限制。 TRANSACTION_UNCOMMITTED（读未提交）:这种隔离级别允许事务读取另一个事务的未提交数据。举例来说，A线程将某帐户的余额减少了1000元，即使在事务A未提交之前，当事务B试图读取该账户余额时，它也将读到减少后的账户余额。在这种隔离级别下，尽管事务A没有提交，但事务B读到的总是最新的数据。但这种隔离级别有一个很严重的问题：读取脏数据！对于前面介绍的情形，当事务B读取到未提交的帐户余额之后，如果事务A又回滚了（没有提交），那意味着B读的数据是不正确的！这就叫读取了脏数据 （有的地方也简称脏读）。 TRANSACTION_READ_COMMITTED（读已提交）