关键词：
最近，一个同事向我们分享了他最近一段时间来对事务的学习成果，我们（都是菜鸟~）就我们当前系统的数据有了疑问，我们当前使用的是乐观锁的形式来保证数据稳定，具体就是版本号的形式。顺便问了一下我们老大，他说我们数据库的隔离级别是读已提交（Read Committed），然后我们就 如果使用乐观锁的话，隔离级别是读未提交还是读已提交的问题产生疑问，这两者是否有区别（从业务层面），如果使用读已提交，是否合理，数据最后能否保证正确等问题。求大神能给解答~万分感谢。咳咳，只说结果的恕我无法理解。。
术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。
隔离级别的产生
在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。
事务的4种隔离级别
READ UNCOMMITTED 未提交读，可以读取未提交的数据。READ COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE 序列化
在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL 语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）
1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）
整形，对值具有唯一约束条件的数据范围 1～5 ，
已有数据1、2、3、4、5，此时数据范围已被完全填充；
整形，对值具有唯一约束条件的数据范围 1 和 5 ，
已有数据1、5，此时数据范围已被完全填充；
2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）
整形的数据范围 1～5 ，
已有数据 1、2、3、4、5，但是因为没有唯一约束，
所以数据范围可以继续被 1～5 的数据重复填充；
整形，具有唯一约束条件的数据范围 1～5 ，
已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；
3. 数据范围内没有任何数据（存在间隙）
如下：
整形的数据范围 1～5 ，数据范围内当前没有任何数据。
在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。
1. 范围内已有数据更改导致的：
更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，
由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；
脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。
这时，另外一个事务也来读取同一条记录，如果不加控制，
第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。
这种现象就叫“脏读”。
2. 范围内数据量发生了变化导致：
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，
却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。
这种现象就叫“不可重复读”。
幻读：一个事务按相同的查询条件重新读取以前检索过的数据，
却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。
可以简单的认为满足条件的数据量变化了。
因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。
MySQL 隔离级别的实现
InnoDB 通过加锁的策略来支持这些隔离级别。
行锁包含：
Record Locks
索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，
这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。
Gap Locks
间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。
间隙锁是性能和并发之间权衡的一部分。
对于无间隙的数据范围不需要间隙锁，因为没有间隙。
Next-Key Locks
索引记录上的记录锁和索引记录之前的 gap lock 的组合。
假设索引包含 10、11、13 和 20。
可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：
(负无穷大, 10] (10, 11] (11, 13] (13, 20] (20, 正无穷大) 对于最后一个间隔，next-key将会锁定索引中最大值的上方，
左右滑动进行查看
"上确界"伪记录的值高于索引中任何实际值。
上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。
基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。
对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。
默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。
READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。
对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，
以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。
总结&延展：
唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。
当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。
行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。
例如，
在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。
session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。
session A 通过索引 idA，session B通过索引 idB 。
当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。
比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。
间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。
rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。
rr 模式下，为了防止幻读，会加上 Gap Locks。
事务中，SQL 开始则加锁，事务结束才释放锁。
就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。
就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。
锁只是并发控制的一种粒度，只是一个很小的部分：
从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)
并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)
粒度加载的安全&性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。
mysql有个多版本控制MVCC，可以认为MVCC是行级锁的一个变种，但他在很多情况下避免了加锁操作，因此开销更低。MVCC实际上是乐观并发控制的，通过每行的记录后面保存两个隐藏的列实现，一个是创建时间，一个是删除时间，当然实际存储的不是时间值，而是版本号。
MVCC只在repeatable read和read committed两个级别下工作，其他隔离级别都和MVCC不兼容，因为read uncommitted总是读到最新数据，而不是符合当前事务版本的数据行。
综上所述，乐观锁是和读已提交搭配使用是可以的 参考技术B
大部分 都是读已提交(read committed),
未提交读是无意义的.事务本来就是保证一致性的
事务进行中本身就不知道结果是成功还是失败
只有进行完毕才算是真正的写入数据库, Read unCommitted(脏读)所以实际运用很少,而且会
导致很多问题
很多时候,你可以自己 实践 一下 :
$db = mysqli_connect(...省略..);$db->autocommit(false);
$sql= "update table set value = value + 10 where id = 1";
$db->query($sql); //执行语句
sleep(20);//延迟20秒
$db->commit(); //提交
mysqli_close($db);
//上面进行事务的同时,你select 该行,看看 值是 提交前还是提交后
//自己实践就出真理,记得更牢,说太多理论,反而听的不清不楚追问
嗯。您说的我明白，主要是同事说读未提交比读已提交在数据库中消费的性能更小，由此我们才纠结要不要换的。因为我们讨论了十来分钟，实在是没有考虑出会出问题的实际业务场景。因为我们了解的不够，所以感觉使用读未提交能提高数据库性能且并不影响使用。。
面试官：说一下mysql事务隔离级别？
...别总共有以下4种：READUNCOMMITTED：读未提交。READCOMMITTED：读已提交。REPEATABLEREAD：可重复读。SERIALIZABLE：序列化。1.四种事务隔离级别1.1READUNCOMMITTED读未提交，也叫未提交读，该隔离级别的事务可以看到其他事务中未提交的数据。... 查看详情
图解数据库事务的隔离级别(代码片段)
前言乐观锁和悲观锁与数据库的隔离级别的关系或者两者使用的场景是什么？我在网上所能找到的答案，帮助个人的理解。答案一：事务隔离级别是并发控制的整体解决方案，其实际上是综合利用各种类型的锁和行版本控制... 查看详情
四种事务隔离级别
... 故读未提交，可能会出现脏读。 第二种：读已提交（readcommitted），也称不可重复读 第一个事务未提交更新的数据，第二个事务读不到； 第一个事务提交更新的数据，第二个事务可以读... 查看详情
事务隔离级别
...别是最低的，会导致引发脏读，不可重复读，和幻读。2.读已提交（ReadCommitte 查看详情
2.事务隔离级别
...别人改数据的事务尚未提交，我在我的事务中也能读到。读已提交：别人改数据的事务已经提交，我在我的事务中才能读到。可重复读：别人改数据的事务已经提交，我在我的事务中也不去读。串行：我的事务尚未提交，别人就... 查看详情
程序员面试宝典之mysql数据库innodb引擎的4个隔离级别
...：可重复读的实现原理答：使用了MVCC多版本控制（类似乐观锁），Innodb引擎会给每一行数据加一个版本号信息，当一个事务修改一个数据时会增加它的版本号+1，当一个事务开始的时候会缓存下此时的版本号，后面读取的时候只... 查看详情
面试官：说一下mysql事务隔离级别？(代码片段)
...下4种：READUNCOMMITTED：读未提交。READCOMMITTED：读已提交。REPEATABLEREAD：可重复读。SERIALIZABLE：序列化。1.四种事务隔离级别1.1READUNCOMMITTED读未提交& 查看详情
5分钟带你读懂事务隔离性与隔离级别(代码片段)
....1事务的隔离级别分为：Readuncommitted(读未提交)ReadCommitted(读已提交)RepeatableReads(可重复读)Serializable(串行化)Readuncommitted读未提交：隔离级别最低的一种事务级别。在这种隔离级别下，会引发脏读、不可重复读和幻读。ReadCommitted读... 查看详情
mysql高级篇——事务的隔离级别与简单应用(代码片段)
...例实操3.1查看与修改MySQL的隔离级别3.2读未提交-举例3.3 读已提交-举例3.4 可重复读-举例3.5 幻读-举例1.数据并发所存在的问题针对事务的隔离性和并发性，我们怎么做取舍呢？先看一下访问相同数据的事务在不保证串行... 查看详情
数据库事务的隔离级别
...重复读)：可避免脏读、不可重复读的发生。③Readcommitted(读已提交)：可避免脏读的发生。④Readuncommitted(读未提交)：最低级别，任何情况都无法保证。 以上四种隔离级别最高的是Serializable级别，最低的是 查看详情
mysql的事务
...致很多问题，实际应用中很少使用。READCOMMITED（读已提交）一个事物开始时 查看详情
数据库原理
...复读）：可避免脏读、不可重复读。 3、Readcommitted（读已提交）：可避免脏读。 4、Readuncommitted（读未提交）：最低级别，无法保证。 mysql默认事务隔离级别为：Repeatableread（可重复读）sqlserver默认事务隔离级别为：Readc... 查看详情
事务的隔离级别(代码片段)
...别是理论上的，大多数的数据库隔离级别都是二档起步*/读已提交读的时候事务还没有提交，后来事务B提交了，再读的结果不一样就是前后不一致意思不能动态读取/*事务A开启以后，只能读取事务B提交之后的数据这种隔离级别... 查看详情
事务-update操作一点观察
隔离级别为读已提交如果数据库的隔离级别是读已提交（ReadCommitted），这是很多数据库默认的隔离级别。在这种情况下：如果事务要更新一条记录，而这条记录恰好被另一个运行中但未提交事务更改（被锁定或删除），则当前... 查看详情
数据库乐观锁与悲观锁
...的锁定操作，所以下面简单总结下数据库的两种类型锁：乐观和悲观锁，很多是概念性的东西和个人理解，不足之处也请指正。一、锁的概念 简单说说数据库锁的概念，和多线程中的锁类似，数据库中对数据的锁定其实也是... 查看详情
事务的隔离级别，乐观锁，悲观锁(代码片段)
事务是有隔离级别readuncommited(读未提交)：不做任何隔离，具有脏读，不可重复对，幻读的问题readcommitted（读提交）：可以防止脏读，不能防止不可重复读和幻读的问题repeatedread（可重复读）：可以防止脏读，不可重复读，不能... 查看详情
面试官问：mysql锁与事物隔离级别你知道吗？(代码片段)
...与算法、MySQL性能优化篇一些内容。我们再来聊聊MySQL的锁与事务隔离级别，分上下两篇，本篇重点讲MySQL的行锁与事务隔离级别。锁定义锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除了传统的计算资... 查看详情
第36讲谈谈mysql支持的事务隔离级别，以及悲观锁和乐观锁的原理和应用场景
...。今天这一讲，作为补充Java面试考察知识点的完整性，关于数据库的应用和细节还需要在实践中深入学习。今天我要问你的问题是，谈谈MySQL支持的事务隔离级别，以及悲观锁和乐观锁的原理和应用场 查看详情