13518219792
事务的隔离级别
成都创新互联公司专注于定结网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供定结营销型网站建设，定结网站制作、定结网页设计、定结网站官网定制、微信小程序开发服务，打造定结网络公司原创品牌,更为您提供定结网站排名全网营销落地服务。
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。
√: 可能出现 ×: 不会出现
脏读不可重复读幻读
Read uncommitted√√√
Read committed×√√
Repeatable read××√
Serializable×××
注意：我们讨论隔离级别的场景，主要是在多个事务并发的情况下，因此，接下来的讲解都围绕事务并发。
Read uncommitted 读未提交
公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而 singo正好去查看账户，发现工资已经到账，是5000元整，非常高兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速 回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有2000元，singo空欢喜一场。
出现上述情况，即我们所说的脏读，两个并发的事务，“事务A：领导给singo发工资”、“事务B：singo查询工资账户”，事务B读取了事务A尚未提交的数据。
当隔离级别设置为Read uncommitted时，就可能出现脏读，如何避免脏读，请看下一个隔离级别。
Read committed 读提交
singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好 在网上转账，把singo工资卡的2000元转到另一账户，并在singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有 钱，扣款失败，singo十分纳闷，明明卡里有钱，为何......
出现上述情况，即我们所说的不可重复读，两个并发的事务，“事务A：singo消费”、“事务B：singo的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。
当隔离级别设置为Read committed时，避免了脏读，但是可能会造成不可重复读。
大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。
Repeatable read 重复读
当隔离级别设置为Repeatable read时，可以避免不可重复读。当singo拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），singo的老婆就不可能对该记录进行修改，也就是singo的老婆不能在此时转账。
虽然Repeatable read避免了不可重复读，但还有可能出现幻读。
singo的老婆工作在银行部门，她时常通过银行内部系统查看singo的信用卡消费 记录。有一天，她正在查询到singo当月信用卡的总消费金额（select sum(amount) from transaction where month = 本月）为80元，而singo此时正好在外面胡吃海塞后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction ... ），并提交了事务，随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，singo的老婆很诧异，以为出 现了幻觉，幻读就这样产生了。
注：Mysql的默认隔离级别就是Repeatable read。
Serializable 序列化
Serializable是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻像读。
首选你需要了解一下 数据脏读，幻读，等一些概念，其次是你要了解一下锁这个概念，当一条数据被读取时，处于锁状态，其他的用户无法对其进行操作。
1.设置为可重复读
SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;
2.首先TB做出一次查询，此时name为bb
3.TA对数据进行修改，并提交
4.此时加入session C作为对比，使用自动事务并做出查询，可见数据已经被修改
5.在已经开启事务的TB中，查询到的，仍然是数据开启事务之前的状态，所以数据是可重复读的
可重复读隔离级别中，每当事务开始后，第一次执行sql语句时（或者执行START TRANSACTION WITH CONSISTENT SNAPSHOT）MVCC会建立一个read view，选取当时的系统版本号，作为事务版本号，以Undo log的行系统版本号与事务版本号进行对比，增删改查都要遵循如下模式：
SELECT：
1, InnoDB只查找版本早于当前事务版本的数据行(行的系统版本号小于等于事务版本号)，这样可以确保事务读取的行，要么是事务开始前就存在的，要么是事务自身插入的或修改过的。
2, 行的删除号要么未定义，要么大于当前事务版本号，这样可以确保事务读取到的行，在事务开始之前未被删除。
INSERT：
InnoDB 为新插入的每一行保存当前系统版本号做为行版本号。
DELETE：
INNODB 为删除的每一行保存当前系统版本号作为行删除标识。
UPDATE：
InnoDB 为插入的每一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。
所以READ COMMITTED和REPEATABLE READ的区别在于，READ COMMITTED总是读取被锁定行的最新一份快照数据， 所以会有不可重复读的问题。而REPEATABLE READ读取事务开始时行系统版本号小于事务版本号的数据，解决不可重复读的问题。
此外要提的一点是，MySql的REPEATABLE READ与Oracle的不同，不但解决了不可重复读问题，还解决的“幻读”问题。
幻读的产生：遵循上述增删改查模式，假设TA事务的事物版本号为3，TB早于TA开启事务，TB事物版本号为2，TB先新增一条数据，行数据的版本号为2，并提交。TB提交后，TA查询时，满足“行的系统版本号小于等于事务版本号”的条件，可以查到数据，形成“幻读”。
InnoDB采用Next-key Lock(间隙锁)来避免“幻读”问题。
Record Lock：单个行记录的锁，锁定的是索引而非记录本身。
GAP Lock：间隙锁，锁定一个范围，但不包含记录本身。
Next-Key Lock：Gap Lock+Record Lock 锁定一个范围并锁定记录本身。
举例说明：
某表字段为ID和NAME，有3条睡觉，ID分别为10，20，50。
如果索引为 10，20，50，那么：
Record Lock：select * from tab where id = 10 for update; //对id=10单行进行加锁
Gap Lock锁范围：（-∞，10）（10，20）（20，50）（50，+∞）
Next-Key Lock锁范围：（-∞，10] （10，20] （20，50] （50，+∞）
当查询的索引含有唯一属性时，InnoDB会对Next-Key Lock进行优化，将其降级为Record Lock，即仅锁住索引本身，而不是范围。
虽然避免了幻读问题，但是还有个特殊情况，感觉可以叫做“幻改”，即当前事务修改了本身并不能查询到的数据。这也是MVCC造成的假象，当前事务虽然查询不到其他事务提交的数据，但是可以对其他事务提交的数据进行修改。
我们设想一个场景，这个场景中我们需要插入多条相关联的数据到数据库，不幸的是，这个过程可能会遇到下面这些问题：
上面的任何一个问题都可能会导致数据的不一致性。为了保证数据的一致性，系统必须能够处理这些问题。事务就是我们抽象出来简化这些问题的首选机制。事务的概念起源于数据库，目前，已经成为一个比较广泛的概念。
何为事务？ 一言蔽之， 事务是逻辑上的一组操作，要么都执行，要么都不执行。
事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账 1000 元，这个转账会涉及到两个关键操作，这两个操作必须都成功或者都失败。
事务会把这两个操作就可以看成逻辑上的一个整体，这个整体包含的操作要么都成功，要么都要失败。这样就不会出现小明余额减少而小红的余额却并没有增加的情况。
大多数情况下，我们在谈论事务的时候，如果没有特指 分布式事务 ，往往指的就是 数据库事务 。
数据库事务在我们日常开发中接触的最多了。如果你的项目属于单体架构的话，你接触到的往往就是数据库事务了。
那数据库事务有什么作用呢？
简单来说，数据库事务可以保证多个对数据库的操作（也就是 SQL 语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循： 要么全部执行成功,要么全部不执行 。
另外，关系型数据库（例如： MySQL 、 SQL Server 、 Oracle 等）事务都有 ACID 特性：
ACID
这里要额外补充一点： 只有保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。也就是说 A、I、D 是手段，C 是目的！
在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对同一数据进行操作）。并发虽然是必须的，但可能会导致以下的问题。
不可重复读和幻读区别 ：不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次查询同一条查询语句（DQL）时，记录发现记录增多或减少了。
SQL 标准定义了四个隔离级别：
隔离级别脏读不可重复读幻读 READ-UNCOMMITTED READ-COMMITTED REPEATABLE-READ SERIALIZABLE
MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。
SERIALIZABLE 隔离级别，是通过锁来实现的。除了 SERIALIZABLE 隔离级别，其他的隔离级别都是基于 MVCC 实现。
不过， SERIALIZABLE 之外的其他隔离级别可能也需要用到锁机制，就比如 REPEATABLE-READ 在当前读情况下需要使用加锁读来保证不会出现幻读。
MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读） 。我们可以通过 SELECT @@tx_isolation; 命令来查看，MySQL 8.0 该命令改为 SELECT @@transaction_isolation;
从上面对 SQL 标准定义了四个隔离级别的介绍可以看出，标准的 SQL 隔离级别定义里，REPEATABLE-READ(可重复读)是不可以防止幻读的。
但是！InnoDB 实现的 REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的，主要有下面两种情况：
因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 READ-COMMITTED ，但是你要知道的是 InnoDB 存储引擎默认使用 REPEATABLE-READ 并不会有任何性能损失。
InnoDB 存储引擎在分布式事务的情况下一般会用到 SERIALIZABLE 隔离级别。
数据库事务及隔离级别
隔离级别：脏读、幻读、一致读、不可重复读、更新丢失
1.脏读（Dirty Reads）：一个事务开始读取了某行数据但是另外一个事务已经更新了此数据但没有能够及时提交。这是相当危险很可能所有操作都被回滚
2.幻读（Phantom Reads）：也称为幻像（幻影）。事务在操作过程中进行两次查询，第二次查询结果包含了第一次查询中未出现的数据（这里并不要求两次查询SQL语句相同）这是因为在两次查询过程中有另外一个事务插入数据造成的
3.不可重复读（Non-repeatable Reads）：一个事务对同一行数据重复读取两次但是却得到了不同结果。例如在两次读取中途有另外一个事务对该行数据进行了修改并提交
4.两次更新问题（Second lost updates problem）：无法重复读取特例，有两个并发事务同时读取同一行数据然后其中一个对它进行修改提交而另一个也进行了修改提交这就会造成第一次写操作失效
5.更新丢失（Lost update）：两个事务都同时更新一行数据但是第二个事务却中途失败退出导致对数据两个修改都失效了这是系统没有执行任何锁操作因此并发事务并没有被隔离开
20、锁是什么？
锁：在所有的DBMS(数据库管理系统)中，锁是实现事务的关键，锁可以保证事务的完整性和并发性。与现实生活中锁一样，它可以使某些数据的拥有者，在某段时间内不能使用某些数据或数据结构。当然锁还分级别的。
锁分为行级锁和表锁。
行级锁：主要是在执行操作过程中，锁定指定的行。
主要的锁行语句有：insert ,update,delete ,及select ....for update。
表锁：指在运行操作指令过程中，由用户指定锁定某张表。lock table XXX in mode share;
共享锁，排他锁，共享排它，行共享，行排他。
锁模式包括?
共享锁:（读取）操作创建的锁。其他用户可以并发读取数据，但任何事物都不能获取数据上的排它锁，直到已释放所有共享锁。
排他锁（X锁）：对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。
更新锁:更新 (U) 锁可以防止通常形式的死锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则两个事务需都要转换共享锁为排它 (X) 锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。
若要避免这种潜 在的死锁问题，请使用更新 (U) 锁。一次只有一个事务可以获得资源的更新 (U) 锁。如果事务修改资源，则更新 (U) 锁转换为排它 (X) 锁。否则，锁转换为共享锁。
锁的粒度主要有以下几种类型：
行锁： 粒度最小，并发性最高
页锁：一次锁定一页。25个行锁可升级为一个页锁。
表锁：粒度大，并发性低
数据库锁：控制整个数据库操作
乐观锁：乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。一般的实现乐观锁的方式就是记录数据版本。
悲观锁：每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁,表锁,读锁,写锁等，都是在做操作之前先上锁。
20、数据库的乐观锁和悲观锁是什么？ oracle 是行级锁
数据库管理系统（DBMS）中，并发控制的任务是：确保在多个事务同时存取同一数据时，不破坏事务的隔离性和统一性以及数据库的统一性。
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。
21、悲观锁和乐观锁的区别，怎么实现
悲观锁：一段执行逻辑加上悲观锁,不同线程同时执行时,只能有一个线程执行,其他的线程在入口处等待,直到锁被释放。
乐观锁：一段执行逻辑加上乐观锁,不同线程同时执行时,可以同时进入执行,在最后更新数据的时候要检查这些数据是否被其他线程修改了(版本和执行初是否相同),没有修改则进行更新,否则放弃本次操作。
1.查看当前会话隔离级别
select @@tx_isolation;
2.查看系统当前隔离级别
select @@global.tx_isolation;
3.设置当前会话隔离级别
set session transaction isolatin level repeatable read;
4.设置系统当前隔离级别
set global transaction isolation level repeatable read;
5.命令行，开始事务时
set autocommit=off 或者 start transaction
关于隔离级别的理解
1.read uncommitted
可以看到未提交的数据（脏读），举个例子：别人说的话你都相信了，但是可能他只是说说，并不实际做。
2.read committed
读取提交的数据。但是，可能多次读取的数据结果不一致（不可重复读，幻读）。用读写的观点就是：读取的行数据，可以写。
3.repeatable read(MySQL默认隔离级别)
可以重复读取，但有幻读。读写观点：读取的数据行不可写，但是可以往表中新增数据。在MySQL中，其他事务新增的数据，看不到，不会产生幻读。采用多版本并发控制（MVCC）机制解决幻读问题。
4.serializable
可读，不可写。像java中的锁，写数据必须等待另一个事务结束。
