你不知道的MySQL事务隔离级别，阿里大佬带你庖丁解牛，深度解析

本文链接：https://blog.csdn.net/python6_quanzhan/article/details/106913720

MySQL是一个服务器／客户端架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每个客户端与服务器连接上之后，就可以称之为一个会话（Session）。我们可以同时在不同的会话里输入各种语句，这些语句可以作为事务的一部分进行处理。不同的会话可以同时发送请求，也就是说服务器可能同时在处理多个事务，这样子就会导致不同的事务可能同时访问到相同的记录。我们前边说过事务有一个特性称之为隔离性，理论上在某个事务对某个数据进行访问时，其他事务应该进行排队，当该事务提交之后，其他事务才可以继续访问这个数据。但是这样子的话对性能影响太大，所以设计数据库的大叔提出了各种隔离级别，来最大限度的提升系统并发处理事务的能力，但是这也是以牺牲一定的隔离性来达到的。

想必事务大家都已经非常熟悉了，它是一组SQL组成的一个执行单元，要么全执行要么全不执行，这也是它的一个特性——原子性。而事务的应用场景也非常广泛，最经典的就是转账问题，A给B打钱，不能出现A钱扣了B还没收到的状况，否则业务就乱套了。

事务的特性

于是呢，根据用户对这些场景的严苛要求，总结出了事务应该具备的四个特性，分别是原子性、一致性、隔离性、持久性，简称事务的ACID属性。

原子性

Atomicity，事务是一个最小的执行单位，事务里面的SQL要么全执行，要么全不执行，就拿A与B转账为例，一条语句从A里扣钱，另一条语句往B身上加钱，如果这两条语句不能全部执行，而是成功了一部分，那事务就没有存在的意义了。

隔离性

Isolate，顾名思义就是将事务与另一个事务隔离开，为什么要隔离呢？如果一个事务正在操作的数据被另一个事务修改或删除了，最后的执行结果可能无法达到预期。如果没有隔离性还会导致其他问题，稍后会有所说明。

持久性

Durable，意为事务完成了对数据的修改之后，修改的结果是永久性生效的。

一致性

Consistent，把一致性放在最后讲的原因是前三个比较容易理解，而一致性的概念很模糊。

一致性是指事务使得应用系统从一个正确的状态到另一个正确的状态。

知乎上面一个高赞回答的很特别，原子性、隔离性、持久性是数据库事务的基本特征，而一致性是由AID这三个特征来保证的。

那么怎么理解这句话呢？还拿转账为例，如果A手里有100元，转给B120元，显然A手里的钱不够扣，假如你给金额这一列设置了不能小于0的约束，那么在事务执行的时候监测到约束没被满足，就会回滚，这时可以说事务保证了一致性。同样的，如果你没有添加约束，而是在业务层做了校验，并做了回滚，那么也可以说事务保证了一致性。那如果数据库和业务层都没有做约束呢，A的钱不就变为负数了吗？这实际上也是保证了一致性，因为执行前后并没有破坏任何约束，它的状态一直都是正确的。

事务并发带来的问题

前面讲到了事务的隔离性，如果要提升系统的吞吐量，当有多个任务需要处理时，应当让多个事务同时执行，这就是事务的并发。既然事务存在并发执行，那必然产生同一个数据操作时的冲突问题，来看一下都会出现什么问题。

更新丢失

Lost Update，当两个事务更新同一行数据时，双方都不知道对方的存在，就有可能覆盖对方的修改。比如两个人同时编辑一个文档，最后一个改完的人总会覆盖掉前面那个人的改动。

脏读

Dirty Reads，一个事务在执行时修改了某条数据，另一个事务正好也读取了这条数据，并基于这条数据做了其他操作，因为前一个事务还没提交，如果基于修改后的数据进一步处理，就会产生无法挽回的损失。

不可重复读

Non-Repeatable Reads，同样是两个事务在操作同一数据，如果在事务开始时读了某数据，这时候另一个事务修改了这条数据，等事务再去读这条数据的时候发现已经变了，这就是没办法重复读一条数据。

幻读

Phantom Read，与上方场景相同，事务一开始按某个查询条件没查出任何数据，结果因为另一个事务的影响，再去查时却查到了数据，这种就像产生幻觉了一样，被称作幻读。

事务的四种隔离级别

首先，更新丢失这种问题应该是由应用层来解决的，因为数据库没有办法控制用户不去更新某条数据。但是另外三个问题是可以得到解决的，既然有方案解决解决它不就好了，干嘛还要设置这么多隔离级别呢？

刚才说了，如果我们要性能好、吞吐量提升，那就不得不付出一些代价，如果要做到完全没有副作用，那么就只需要让事务排队执行就好了，一个一个执行绝对不会出现脏读幻读的问题，但是这样会导致数据库处理的非常慢。那怎么办呢？官方唯一能做的就是给你提供各种级别的处理方式，由你根据具体业务场景选择，于是就有了隔离级别。