关于mysql:弱隔离级别-事务并发问题

介绍弱隔离级别

为什么要有弱隔离级别

如果两个事务操作的是不同的数据，即不存在数据依赖关系，则它们能够平安地并行执行。然而当呈现某个事务批改数据而另一个事务同时要读取该数据，或者两个事务同时批改雷同数据时，就会呈现并发问题。

在应用程序的开发中，咱们通常会利用锁进行并发管制，确保临界区的资源不会呈现多个线程同时进行读写的状况，这其实就对应了事务的最高隔离级别：可串行化。可串行化隔离意味着数据库保障事务的最终执行后果与串行（即一次一个，没有任何并发）执行后果雷同。

那么为什么应用程序中能够提供可串行化的隔离级别，而数据库却不能呢？其实根本原因就是应用程序对临界区大多是内存操作，而数据库要保障持久性（Durability），须要把临界区的数据长久化到磁盘，可是磁盘操作比内存操作要慢好几个数量级，一次随机拜访内存、固态硬盘 和 机械硬盘，对应的操作工夫别离为几十纳秒、几十微秒和几十毫秒，这会导致持有锁的工夫变长，对临界区资源的竞争将会变得异样强烈，数据库的性能则会大大降低。

所以，数据库的研究者就对事务定义了隔离级别这个概念，也就是在高性能与正确性之间做一个衡量，相当于明确地通知使用者，咱们提供了正确性差一点然而性能好一点的模式，以及正确性好一点然而性能差一点的模式，使用者能够依据本人的业务场景来抉择一个适合的隔离级别。

弱隔离级别带来的危险

弱隔离级别就是非串行化隔离级别。

较弱的隔离级别，它能够避免某些并发问题，但并非全副的并发问题。

应用这些弱隔离级别，事务并发执行时，可能会出现异常状况，带来一些难以捉摸的隐患，因而，咱们须要理解弱隔离级别存在的并发问题以及如何防备存在的并发问题。而后，咱们就能够应用所把握的工具和办法来构建正确、牢靠的利用。

各种隔离级别

SQL-92 规范定义了 4 种事务的隔离级别：读未提交（Read Uncommitted）、读已提交（Read Committed）、可反复读（Repeatable Read）和可串行化（Serializable），在前面的倒退过程中，又减少了快照隔离级别（Snapshot Isolation）。

不同的弱隔离级别解决了不同的并发问题（正确性问题），同时也存在一些并发问题。

上面是各种隔离级别及对应的并发问题：

• ✔️代表该隔离级别已解决该并发问题；
• ❌代表该隔离级别未解决该并发问题。

SQL 规范对隔离级别的定义还是存在一些缺点，某些定义不置可否，不够准确，且不能做到与实现无关，所以下面的表格只是对常见的隔离级别并发问题的定义，你能够把它当成一个通用的规范参考。

当你应用某一个数据库时，须要读一下它的文档，确定好它的每一种隔离级别具体的并发问题。

• MySQL 的默认隔离级别为：可反复读。
• Oracle、PostgreSQL 的默认隔离级别为：读已提交

事务并发执行时，存在的并发问题

如果两个事务操作的是不同的数据，即不存在数据依赖关系，则它们能够平安地并行执行。然而当呈现某个事务批改数据而另一个事务同时要读取该数据，或者两个事务同时批改雷同数据时，就会呈现并发问题。

并发问题总结：

• 脏写 ：一个事务笼罩了其余事务尚未提交的写入。
• 脏读 ：一个事务读到了其余事务尚未提交的写入。
• 不可反复读 ：一个事务内，屡次读取同一个记录的后果不一样。
• 更新失落 ：两个事务同时执行“读-批改-写回”操作序列，事务 A 笼罩了 事务 B 的写入，但又没有蕴含 事务 B 批改后的值，最终导致了局部更新数据产生了失落。
• 幻读 ：一个事务内，屡次读取满足指定条件的数据，读出来的后果不一样。
• 写歪斜 ：事务首先查问数据，依据返回的后果而作出某些决定，而后批改数据库。当事务提交时，反对决定的前提条件已不再成立。

脏写

一个事务笼罩了其余事务尚未提交的写入。

脏读

一个事务读到了其余事务尚未提交的写入。

举例说明脏读

事务 B 批改了 x，在事务 B 提交之前，事务 A 读到了 x 批改后的数据。这时事务 B 回滚了，相当于事务 A 读到了一个有效的数据（未理论提交到数据库中的数据），事务 A 的读就是脏读。

不可反复读

一个事务内，屡次读取同一个记录的后果不一样。（一个事务可能读到另一个事务对同一个记录的批改）

举例说明不可反复读

事务 A 读取了 x，而后事务 B 批改了 x 并提交。这时事务 A 再次读取 x，发现两次读取同一个记录的后果不一样，这就是不可反复读。

更新失落

两个事务同时执行“读-批改-写回”操作序列，事务 A 笼罩了 事务 B 的写入，但又没有蕴含 事务 B 的批改，最终导致了局部更新数据产生了失落。

举例说明更新失落

事务 A 先读取某记录，而后事务 B 再读取某记录，事务 B 批改并写回，紧接着 事务 A 批改并写入。事务 A 笼罩了 事务 B 的写入，但又没有蕴含 事务 B 的批改，最终导致事务 B 的更新失落了。

幻读

一个事务内，屡次读取满足指定条件的数据，读出来的后果不一样（一个事务可能读到另一个事务创立的满足条件的记录）

举例说明幻读

事务 A 读取一组满足条件 1 的数据，之后事务 B 创立了满足条件 1 的数据，使其满足条件 1 并提交，如果事务 A 用雷同的 条件 1 再次读取，失去一组不同于第一次读取的数据。这就叫幻读。

不可反复读和幻读都是一个事务内，屡次执行雷同的查问，后果不一样。那两者有什么区别呢？

• 幻读 次要说的是，读到了另一个事务的 insert 或者 update 的满足条件的记录
• 不可反复读 次要说的是，读到了另一个事务对同一个记录的 update

写歪斜

写歪斜就是：事务首先查问数据，依据返回的后果而作出某些决定，而后批改数据库。当事务提交时，反对决定的前提条件已不再成立。

如何避免并发问题

当初咱们曾经晓得了每一个隔离级别可能会呈现的并发问题，如果以后数据库应用了某一个隔离级别，咱们也晓得这个隔离级别存在的并发问题，是否有方法来防止并发问题呢？以及对于防止并发问题是如何实现的？

有些并发问题只能通过晋升隔离级别来防止，接下来，咱们就针对每一种并发问题一一探讨。

避免脏写

容许脏写这种并发问题呈现的数据库基本上是不可用的。因而所有的隔离级别都不容许呈现脏写这种并发问题。

避免“脏写”就意味着，写数据库时，只会笼罩已胜利提交的数据。

避免脏写通常的形式是推延第二个写申请，直到后面的事务实现提交（或者停止）。

数据库通常采纳行级锁来避免脏写：如果两个事务同时尝试写入同一个对象时，以加锁的形式来确保第二个写入期待后面事务实现（包含停止或提交）。

这种锁定是由处于读已提交模式（或更强的隔离级别）的数据库主动实现的。

避免脏读

避免“脏读”就意味着，读数据库时，只能看到已胜利提交的数据。

如果业务中不能承受脏读，那么隔离级别要在“读已提交”隔离级别或者以上。

当有以下需要时，须要避免脏读：

• 如果事务须要进行多个操作更新多个对象，咱们须要保障另一个事务或者应用层要么看到所有操作执行前的状态，要么看到所有操作实现后的状态，而不能看到局部操作实现的中间状态。如果咱们要提供这样的保障，那么就必须避免脏读。脏读意味着另一个事务可能会看到局部更新，而非全副，察看到局部更新的数据可能会造成用户的困惑。
• 如果事务产生停止，则所有写入操作都须要回滚，那么就必须避免脏读，防止用户察看到一些稍后被回滚的数据，而这些数据理论并未理论提交到数据库中。

避免脏读的解决方案：

• 两段锁协定；
• 存储数据的旧版本和新版本。

一种抉择是应用和避免脏写雷同的锁，所有试图读取该对象的事务必须先申请锁，事务实现后开释锁，从而确保不会产生读取到一个脏的、未提交的值。

然而，加锁的形式在理论中并不可行，因为运行工夫较长的写事务会导致许多只读的事务期待太长时间，这会重大影响只读事务的响应工夫。应用程序任何部分的性能问题会扩散，进而影响整个利用，产生连锁反应。

因而，大多数数据库采纳了上面的形式来避免脏读：对于每个待更新的对象，数据库都会保护对象的两个版本（其旧值 和 以后持锁事务将要设置的新值）。在事务提交之前，其余事务的读操作都读取旧值；仅当写事务提交之后，才会切换到读取新值。而 MySQL 应用了多版本并发管制来避免脏读，多版本比两个版本更加通用。

避免不可反复读

避免“不可反复读”就意味着，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是统一的。

不能忍耐不可反复读的场景：

• 备份场景 ：备份工作要复制整个数据库，这可能须要破费几小时能力实现。在备份过程中，数据能够持续写入数据库。因而，备份里可能蕴含局部旧版本数据和局部新版本数据。如果从这样的备份进行复原，那么就导致了永久性的不统一。

如果业务中不能承受不可反复读，那么隔离级别要在“可反复读”隔离级别或者以上。

在 MySQL 种，可反复读隔离级别即快照级别隔离。快照级别隔离的总体想法是：每个事务总是在某个工夫点的一致性快照中读取数据。

为了实现快照级别隔离，MySQL 数据库采纳了一种被称为多版本并发管制（MultiVersion Concurrency Control，MVCC）的机制。

避免更新失落

更新失落可能产生在这样一个操作场景中：应用程序从数据库读取某些值，依据应用逻辑做出批改，而后写回新值（read-midify-write 过程）。当有两个事务在同样的数据对象上执行相似操作时，后一个写操作并不蕴含前一个写操作的批改，最终导致前一个写操作的批改失落。

更新失落属于写事务并发抵触。

避免更新失落，目前有多种可行的解决方案。

• 原子更新操作 ：许多数据库提供了原子更新操作，以防止在应用层代码实现“读-批改-写回”操作序列，如果数据库反对原子更新操作的话，通常这就是避免更新失落最好的解决方案。
• • 原子操作通常采纳对读取对象加独占锁的形式来实现，这样在更新被提交之前其余事务不能够读取它。
  • 原子操作的另一种实现形式是：强制所有的原子操作都在单线程上执行。这也是 Redis 避免更新失落的解决方案
• 显式的加锁 ：既然原子操作采纳对读取对象加独占锁的形式来实现，那么咱们也能够显式的锁定待更新的对象，使“读-批改-写回”操作序列串行执行。例如应用 MySQL 的 select …… for update;

原子更新操作和 显式的加锁 都是通过强制“读-批改-写回”操作序列串行执行来避免失落更新。

• 自动检测更新失落 ：先让“读-批改-写回”操作序列并发执行，但如果事务管理器检测到了更新失落危险，则会停止以后事务，并强制回退到平安的“读-批改-写回”形式。
• 比拟并设置 ：先让“读-批改-写回”操作序列并发执行，如果读取的内容曾经产生了变动且值与“旧内容”不匹配，则更新失败，须要应用层再次查看并在必要时进行重试。例如 update t1 set col1 = ‘ 新内容 ’ where id = 1 and col1 = ‘ 旧内容 ’;

自动检测更新失落

PostgreSQL 的可反复读，Oracle 的可串行化以及 SQL Server 的快照级别隔离等，都能够自动检测何时产生了更新失落，而后会停止违规的那个事务。

然而，MySQL 中 InnoDB 存储引擎的可反复读却并不反对自动检测更新失落。

避免幻读 & 写歪斜

避免幻读：

• 应用 可串行化隔离级别
• 在 MySQL 的 可反复读隔离级别下，应用 select …… for update;

应用可串行化隔离级别能够避免幻读。

可串行化隔离通常被认为是最强的隔离级别。应用可串行化隔离级别能够避免所有可能的竞争条件。

可串行化隔离保障即便事务可能会并行执行，但最终的执行后果与每次执行一个事务（即串行执行）的后果雷同。

可串行化隔离级别的实现有以下几种形式：

• 理论串行执行：
• 两段锁 + 索引区间锁：将两段锁与索引区间锁联合应用，实现可串行化隔离
• 可串行化快照隔离：（这个临时还没有理解）

MySQL 的可串行化隔离级别应用了第 2 种办法（两段锁 + 索引区间锁）

写歪斜就是：事务首先查问数据，依据返回的后果而作出某些决定，而后批改数据库。当事务提交时，反对决定的前提条件已不再成立。写歪斜可能产生在这样一个操作场景中：

1. 第一步 select：应用程序从数据库读取一组满足条件 1 的数据
2. 第二步 决定：依据查问的后果，应用层代码来决定下一步的操作（有可能持续，或者报告谬误井停止）
3. 第三步 写入：如果应用程序决定继续执行，它将发动数据库写入（insert，update 或 delete）并提交事务。

而第 3 步的这个写操作会扭转第 2 步做出决定的前提条件，如果两个事务并发执行这样的“读取 - 决定 - 写入”操作序列，那么后一个写入扭转了前一个写入执行的前提条件，导致呈现意料之外的后果。

避免写歪斜

对于写歪斜问题，有几种可能的解决方案：

• 只应用 可串行化隔离级别 即可防止写歪斜（应用索引区间锁，防止其余事务写入满足条件的行）
• 更改“读取 - 决定 - 写入”操作序列的执行程序 为“写入 - 读取 - 决定”：先写入，而后 select 查问并加独占锁（select …… for update），最初依据查问的后果来决定是否提交或者放弃。
• 实体化抵触，也称物化抵触：有的业务场景 select 查问的是不满足给定搜寻条件的行（例如 select * from t1 where id != 1）如果第 1 步的查问基本没有返回任何行，则 select …… for update 也就无从加锁，只能思考实体化抵触。

实质上这三种可能的解决方案都是对事务所依赖的行显式的加锁。

对于实体化抵触（物化抵触）的阐明

如果问题的要害是查问后果中没有对象（空）能够加锁，或者能够人为引人一些可加锁的对象。这种办法称为实体化抵触（或物化抵触），它把幻读问题转变为针对数据库中一组具体行的锁抵触问题。

然而，弄清楚如何实现实体化往往也具备挑战性，实现过程也容易出错，这种把一个并发管制机制降级为数据模型的思路总是不够优雅。出于这些起因，除非万不得己，没有其余可选计划，不举荐采纳实体化抵触。

参考资料

24|事务（三）：隔离性，正确与性能之间衡量的艺术 - 极客工夫 (geekbang.org)

《数据密集型利用零碎设计》