• 详解MySQL隔离级别


    一个事务具有ACID特性,也就是(Atomicity、Consistency、Isolation、Durability,即原子性一致性隔离性持久性),本文主要讲解一下其中的Isolation,也就是事务的隔离性

    概述

    四种隔离级别分别是:

    • 读未提交(read uncommitted)
      • 一个事务还没提交时,它修改的数据都可以被别的事物看到。
    • 读已提交(read committed)
      • 一个事务提交之后,它修改的数据才会被别的事物看到。
    • 可重复读(repeatable read)
      • 一个事务执行过程中看到的数据,总是和这个事务开启时看到的数据是一致的。在可重复读的隔离级别下,未提交的事务对其他事务也是不可见的。
    • 串行化(serializable)
      • 数据的都会加锁会加读锁会加写锁。当遇到读写锁冲突时,后访问的事务必须等前一个事务执行完成后,再继续执行。

    以上四种隔离级别,由上往下隔离强度越来越大,但是执行效率会随之降低。在设置隔离级别时候,需要在隔离级别执行效率两者做平衡取舍。

    为了便于理解,下面就举一个例子:

    在不同隔离级别下,事务A会有哪些不同的返回结果,也就是图中的V1V2V3的返回值分别是什么。

    • 如果隔离级别是读未提交,事务B修改后数据无需提交事务,就能被事务A读取,所以V1V2V3的值都是2
    • 如果隔离级别是读已提交,事务B修改后需要提交后,修改后的数据才能被事务A读取,所以V1的值是1事务B提交,事务A读取修改后的数据,所以V2的值是2,V3的值也是2
    • 如果隔离级别是可重复读,整个事务看到的事务和事务开启时看到的数据是一致的,开启看到的数据是1,所以V1V2的值都是1,事务A提交之后,获取到修改后的数据,所以V3的值是2
    • 如果隔离级别是串行化,会被锁住,此时事务B对应的线程处于阻塞状态,直到事务A提交之后,事务B才会继续将1改成2。所以V1V2的值是1V3的值是2

    MySQL默认的隔离级别是可重复读

    隔离级问题

    先了解几个基本概念:

    脏读事务A修改数据,事务B读取了数据后事务A报错回滚,修改的数据没有提交到数据库中,此时事务B读取修改的数据就是一个脏读,也就是一个事务读取到另一个事务未提交的数据就是脏读

    不可重复读事务A在同一个事务上多次读取同一个数据,在事务A还没有结束时,事务B修改了该数据,由于事务B的修改,导致事务A两次读取的数据不一致,就出现了不可以重复读的现象。

    幻读事务A根据条件查询得到N条数据,但此时事务B更改或者增加了M条符合事务A查询的条件的数据。这样当事务A再次查询的时候发现会有N + M条数据,产生了幻读。

    几种隔离级别可能会有脏读不可重复读或者幻读的问题,它们之间的关系如下:

    隔离级别 脏读 不可重复读 幻读
    读未提交
    读提交 ×
    可重复读 × ×
    串行化 × × ×
    • 读未提交:可能会出现脏读不可重复读幻读,读取未提交事务的数据,数据撤回了,就是一种脏读。如果其他事务修改同一个数据,事务读取的数据也是不同的,所以也存在不可重复读。同时也能读取到其他事务添加的数据,所以也存在幻读
    • 读已提交:该隔离级别只能读取到其他事务提交后的数据,所以不存在脏读。但是在第一次读取数据后,其他事务修改后数据并提交事务,此时事务读取到数据就和第一次读到的数据不一致了,也就存在不可重复读。同时其他事务可以添加多条数据,也存在幻读
    • 可重复度读:表示整个事务看到的事务和开启后的事务能看到的数据是一致的,既然数据是一致的,所以不存在不可重复读。而且不会读取其他事务修改的数据,也就是不存在脏读。而对同一个批数据,可能会存在添加的情况,所以可能会存在幻读的情况。
    • 窜行化:当发生读写锁冲突时,后面的事务要等前面的事务执行完毕之后再执行,所以一定是先读或者先写的执行完毕之后再执行后读或者写,读写按照顺序依次进行,所以不存在脏读不存在不可重复读也不存在幻读

    隔离级别原理

    隔离级别的主要是多版本并发控制MVCC,MVCC是通过保存数据在某个时间点的快照来实现的。

    InnoDB实现的MVCC,是通过在每行记录后面保存两个隐藏列来实现,一个是保存行的创建时间,另一个是保存行的过期时间。当然存储的不是时间,而是系统版本号。每开启一个新的事务,系统版本号先自动递增,该系统版本号会作为事务的版本号,用来和查询到的每行记录的版本号做比较。比如在可重复读隔离级别下,MVCC是如何操作的:

    • SELECT
      • InnoDB会根据以下两个条件检查每行记录:
          1. InnoDB只查找版本号早于当前事务的数据行(系统版本号小于或者等于事务的系统版本号),这样可以确保事务读取的行,要么是在事务开始前就存在,要么是事务自身插入或者更新过。
          1. 行的删除版本要么未定义,要么大于当前事务版本号。这可以确保事务读取到的行,在事务开始之前未被删除。
      • 只有符合上述两个条件的记录,才能返回作为查询的结果。
    • INSERT
      • InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
    • DELETE
      • InnoDB为删除的每一行保存当前系统版本号作为行删除的标识。
    • UPDATE
      • InnoDB为插入一行新记录,保存当前系统版本号作为行版本号,同时保存当前系统版本号到原来的行作为行删除标识。

    保存着两个额外的系统版本号,大多数读操作都可以不用加锁。这样设计是的读数据的操作很简单,性能很好,并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间,需要做更多的行检查工作,以及一些额外的维护工作。

    MVCC只在读已提交可重复读两个隔离级别下生效。其他两个隔离级别下MVCC都不能生效,因为读未提交总是读取到最新的数据行,无需记录当前事务版本号。而串行化会对所有的读写都会进行加锁,先读、先写的先执行,后读后写的后执行。也不需要记录记录版本号精心比对。

    InnoDB的行数据有多个版本,每个数据版本都有自己的row trx_id,每个事务或者语句都有自己的一致性视图。查询语句是一致性读,一致性读会根据row trx_id和一致性视图确定数据版本的可见性。

    • 可重复读,只查询在事务启动前就提交完成的数据。
    • 读已提交,只查询语句启动前其他事务提交的数据。

    总结

    • 四种隔离级别:

      • 读未提交:数据会读取其他事务未更新到数据的数据。可能会存在脏读不可重复读幻读的问题。
      • 读已提交(read committed):数据只能读取其他事务提交的数据,不存在脏读,但是可能会存在不可重复读幻读的问题。
      • 可重复读(repeatable read):事务执行过程中看到的数据,总是和这个事务开启时看到的数据是一致的。在可重复读的隔离级别下,未提交的事务对其他事务也是不可见的。不存在脏读不可重复读,但是可能会存在幻读问题。
      • 串行化(serializable):存在读写锁冲突时,后访问的事务会等前一个事务执行完毕后,再继续执行。
    • MySQL采用了MVVC(多版本并发控制)解决读已提交可重复读隔离问题。

      • 执行一条SQL语句,都会保存两个隐藏的列。一个是保存创建时间,一个保存过期时间,储存的系统版本号
      • 每次开启一个事务都会系统会递增一个系统版本号,作为事务的版本号。
        • select,查询早于当前事务的数据。
        • insert添加版本号。
        • delete为删除的行把版本号作为删除标识。
        • update,先插入一条数据,保存当前系统版本号。同时保存原来的行作为行删除标志。

    参考

    事务到底是隔离的还是不隔离的?

    高性能MySQL

  • 相关阅读:
    C++17中头文件filesystem的使用
    C++内存管理(new和delete)
    Mybatis的parameterType造成线程阻塞问题分析
    告警:线上慎用 BigDecimal ,坑的差点被开了
    百云齐鲁 | 云轴科技ZStack成功实践精选(山东)
    Pytest用例自定义 - 重复、并行、串行
    用浏览器快速开启Docker的体验之旅
    Node 调试利器,前端、Node 开发必备 - VSCode JS Debug Terminal
    Run ORB_SLAM2 Under ROS/Example
    ctfshow XSS
  • 原文地址:https://www.cnblogs.com/jeremylai7/p/16623780.html