MySQL事务中四种隔离级别

READUNCOMMITTED：脏读。
事务A的更改没有提交，但是事务B读取了它们。
Oracle DB2 于 2 008 年首次正式记录。
这是一个陷阱，不要相信。

READCOMMITTED：读取不能重复。
事务 B 在事务 A 读取时进行修改。
Oracle RAC 于 2 004 年推出。
除非您的要求很低，否则不要这样做。

REPEatableread：幻读。
事务A开始后，事务B插入新数据。
MySQL 5 .6 标准。
实际上使用MVCC。

SERIALIZABLE：序列化。
锁定工作台，完全绝缘。
Oracle 1 2 c 标准。
只用，不用。

选择隔离级别：看业务。
为了获得高一致性，请选择 SERIALIZABLE。

mysql隔离级别有几种

上周朋友在研究数据库隔离级别，发现MySQL有四种类型：ReadUncommissed、ReadCommited、RepeatableRead、Serialized。
ReadUncommited 允许读取未提交的数据，但可能导致脏读，并且很少使用。
ReadCommited避免了脏读，但可能会出现冗余读。
MySQL默认的RepeatableRead通过MVCC保证数据一致性，但可能会出现误读。
Serialized级别最高，但性能最差，适用于低并发、高一致性的情况。
选择可提供一致性和性能的隔离级别。
我刚才想到的另外一个问题就是不同级别的隔离如何解决脏读、非重复读、伪读的问题。
算了，你都知道的。

最易懂的数据库事务的四种隔离级别知识

不幸的是，当谈到数据库事务的隔离级别时，我实际上对此有一些经验。
将其视为正常的餐后谈话，我会向您详细介绍。

我们先说一个更简单的例子。
想象一下，有一个程序员小哥，他的月薪是3 6 000元。
当老板给他发这个月的工资时，他的手一抖，又多发了9 000元。
钱到了，老板还没有成交。
这时，弟弟看着自己的账户，高兴极了，以为自己升职了，加薪了。
然后老板就意识到不对劲，赶紧改回来。
这是典型的“脏读”，即小弟读到了老大没有提交的“脏数据”。

接下来我们来谈谈“阅读提交”。
又是这个弟弟。
他去超市用信用卡买东西，付款时系统检测到他有3 6 000。
这时，他的妻子将所有的钱转给了他，并进行了转账交易。
当系统查看哥哥的余额，准备扣钱的时候，却发现钱不见了。
这种情况称为“不可重复读”，因为同一事务中两次查询的结果不一致。

我们再举一个“反复阅读”的例子。
我哥哥仍然使用信用卡。
付款时，系统检测到他有3 6 000。
这时，他的妻子想要转账，但由于交易是公开的，所以她的转账操作被阻止了。
这样，在交易开始期间，小弟的余额就会保持稳定。
这就是“反复阅读”。

最后，我们要谈谈“序列化”。
就好像所有的操作都是一个接一个地完成的。
完成一笔交易后，即可开始下一笔交易。
这样可以避免任何问题，但缺点是效率太低，往往不被使用。

最终，这些隔离级别旨在防止数据不一致。
就像我们平时说话的时候，一定要注意对方说完之后不要再说话，否则就会出现混乱。

对于MySQL来说，它的默认隔离级别是“repeatable read”，即可重复读。
它可以避免误读和不重复读数，但误读仍然可能发生。
一些大厂商选择“读提交”主要是因为它可以提高并发性能，减少死锁。

为了解决虚拟读的问题，MySQL有自己的方法，比如MVCC、多版本并发控制等。
简而言之，通过记录不同版本的数据来避免出现问题。

总之，这四个隔离级别中的每一个都有其自己的用途和局限性。
您选择哪一种取决于您的具体需求和场景。
希望我作为“老司机”的经历可以帮助你更好的理解。