• 事务+事务并发+事务隔离级别【Interview Question】


    目录

    1什么是事务?

    2事务的四大特性?

    3MySql事务是如何保证ACID四大特性的?

    4mysql事务的执行流程?

    5事务的并发有哪些问题?

    6事务隔离级别有那些?分别解决了什么问题?

    7事务隔离级别的原理?

    8什么是丢失更新,如何解决?


    1什么是事务?

    事务就是操作数据库的最小执行单元,一个事务内的操作要么全部成功,要么全部失败,保证数据的一致性。

    2事务的四大特性?

    事务的四大特性(ACID):原子性Atomicity 一致性Consistency 隔离性Isolation 持久性Durability

    原子性:一个事务内的操作要么全部成功,要么全部失败。

    持久性:事务一旦提交【不能回滚】将数据持久化到磁盘中,保证数据不会丢失

    隔离性:【事务之间互不影响】两个事务修改同一个数据,必须按顺序执行,并且前一个事务如果未完成,那么中间状态对另一个事务不可见

    一致性:【事务执行前后都必须保证数据的总和是一致的】要求任何写到数据库的数据都必须满足预先定义的规则,它基于其他三个特性实现的【【转账的前后金额是一致的,少100,那边就会多100】 】

    ======================ACID拓展=============================

    原子性:事务的原子性是如何保证的?就是如何保证事务回滚时,能够获取到以前的数据?

    主要是利用Innodb的undolog日志(回滚日志),当事务进行回滚的时候能够根据undolog日志获取到原本的数据。

    持久性:持久性的关键就是事务一旦提交,不能进行回滚。通过undolog实现事务的原子性,通过redolog实现事务的持久性。

    undolog是记录旧数据的备份,redolog是记录新数据的备份。

    在事务提交之前,只需要将redolog日志进行持久化到磁盘当中,不需要将数据持久化到数据库中。当系统崩溃时,虽然数据没有持久化到数据库当中,但是可以通过Redolog日志获取到新数据,将所有数据恢复到最新的状态。

    3MySql事务是如何保证ACID四大特性的?

    1.Mysql是如何保证一致性的?【数据的一致性】

    从数据库层面,数据库通过原子性,隔离性和持久性来保证 一致性

    所以说ACID中C(一致性【数据一致性】)是目的原子性,隔离性,持久性三个是保证数据的一致性的手段。所以要想保证数据的一致性就需要保证事务中的原子性和隔离性和持久性。第二种,2采用排他锁,就是对当前数据进行操作时就进行加锁,其他事务不能进行操作该数据,只有等待当前线程执行完成释放锁过后才能获取锁。

    2Mysql是如何保证原子性的?【要么同时成功,要么同时失败】

    使用Innodb的undo log日志(进行回滚)用来记录旧的是数据,当事务执行失败,进行回滚就可以从undolog日志中获取原本的数据。

    简明知意,就是回滚日志,是实现原子性的关键,当事务回滚时能够撤销已经执行成功的sql语句,并执行日志中的sql语句恢复旧数据。

    3.Mysql是如何保证持久性的?【事务一旦提交不能进行回滚】

    利用innodb的redo log日志。

    redo log记录的是新数据的备份,在事务提交前,需要将Redo Log持久化到磁盘当中,不需要将数据持久化,当系统崩溃时,虽然数据没有持久化,系统可以根据redo Log的内容,将所有数据恢复到最新的状态

    4mysql事务的执行流程?

    宏观上:开启事务,执行事务,提交事务,出现异常回滚事务。

    实际上(举例说明):条件:事务需要将A=1修改成A=3。

    执行流程:首先开启事务,将A=1存储到undolog日志用于回滚,修改A=3并将A=3存储到redolog日志(用于存储最新的数据),将redolog持久化到磁盘当中,修改成功,提交事务。

    1.A.开启事务.
    2.B.记录A=1到undo log.
    3.C.修改A=3.
    4.D.记录A=3到redo log.
    5.E.记录B=2到undo log.
    6.F.修改B=4.
    7.G.记录B=4到redo log.
    8.H.将redo log写入磁盘。
    I.事务提交

    5事务的并发有哪些问题?

    首先要知道为了会造成事务并发,就是当多个事务对数据库的共享资源(例如数据库的一行数据)进行并发操作,从而导致数据不一致的问题

    事务的并发可能出现那些问题呢?

    1脏读:读取到的数据可能是其他事务未提交到数据库的数据。【就是读取到其他事务正在修改的数据,但这个事务不一定会将这个数据提交到数据库】

    2不可重复读:同一个事务中多次使用相同条件读取到的数据值不一致

    3幻读:同一个事务使用相同的条件读取到的数据条数不一致

    第一类丢失更新:也叫回滚丢失,事务A和事务B更新同一条数据,事务B先完成了修改,此时事务A异常终止,回滚后造成事务B的更新也丢失了

    第二类丢失更新:也叫覆盖丢失,事务A和事务B更新同一条数据,事务B先完成了修改,事务A再次修改并提交,把事务B提交的数据给覆盖了

    6事务隔离级别有那些?分别解决了什么问题?

    首先要明白事务隔离级别是什么意思?

    事务隔离级别:指的是一个事务与其他事务的隔离程度。就是用来解决事务并发问题。

    比如脏读,不可重复读,幻读,更行丢失(回滚丢失)/(覆盖丢失)

    事务隔离级别包含4种:

    读未提交(READ UNCOMMITTED):允许事务A能够读取到事务B未提交的数据(三个都可能会出现)。

    读提交(READ COMMITTED):事务A只能读取到事务B已经提交的数据(可能会出现不可重复读和幻读问题)。

    可重复读(REPEATABLE READ):事务A多次读取共享资源(数据)(例如数据库的一行数据),读取的数据值都是一致的(可能会出现幻读)。意思就是在事务A对共享资源进行操作时,其实事务不能对共享资源进行操作。

    串行化(SERIALIZABLE)【乐观锁和悲观锁】:事务A多次读取共享资源,读取到的数据的行和值都是一致的(事务并发问题都不会出现)隔离效果最好,可以解决脏读,不可重复读,幻读的问题。但是性能最低,类似于单线程,事务A对共享资源进行操作时,其他事务必须等待事务A执行结束。

    7事务隔离级别的原理?

    事务隔离级别的原理是读写锁+MVCCMulti Version Concurrency Control -多版本并发控制)。

    读写锁指的是每次读操作都需要一个共享锁(其他事务只要是读取也可以共享这把锁),写操作需要一个写锁(类似于排他锁),共享锁之间和共享锁和写锁之间不会产生互斥,写锁与写锁之间产生互斥,当产生锁(写锁与写锁)竞争时,需要等待上一个操作的锁释放,另一个操作才能获得锁

    MVCC多版本并发控制指的是“维护一个数据的多个版本,就是为了解决读写冲突”,如果是读取数据,会采用一种类似快照的方式将数据保存到undolog日志当中。不同事务的数据快照版本是不一样的,即使其他事务修改了数据,对于当前事务也是不可见的,仍然只会第一次读取快照到undolog日志中的数据。

    可重复读:读取的数据第一次读取快照到undolog日志中的数据(读快照,读取的数据是旧数据)

    读提交则是每次执行语句的时候都重新生成一次快照(当前读-读取的数据是最新的数据)

    8什么是丢失更新,如何解决?

    丢失更新包括:第一类丢失更新(回滚丢失)和第二类丢失更新(覆盖丢失)

    第一类丢失更新:也叫回滚丢失,事务A和事务B更新同一条数据,事务B先完成了修改,此时事务A异常终止,回滚后造成事务B的更新也丢失了

    第二类丢失更新:也叫覆盖丢失,事务A和事务B更新同一条数据,事务B先完成了修改,事务A再次修改并提交,把事务B提交的数据给覆盖了

    如何解决呢?

    采用乐观锁或者悲观锁进行解决。

    悲观锁【适用于写多读少的场景】:读取数据的时候加锁,这样能够保证读到的数据都是最新的数据,并且会将记录锁住,其他事物如果想要获取锁会阻塞。

    乐观锁【适用写少读多的场景】:添加version字段,记录每条记录的更新版本,每次更新后版本号加一。最后进行提交时判断事务刚开始的版本号和最后进行事务提交时候的版本号是否一致,一致才进行事务提交,不一致则不会进行事务提交。

    什么是闭锁

  • 相关阅读:
    保研北京大学计算机研究生的同学,本科都是哪些大学?
    swift 问答app
    C/C++ 数据结构 - 栈
    RabbitMQ之延迟队列
    计算机组成原理 | 总线
    Maven项目打包,出现提示 Lombok 版本和 jdk 的编译器不兼容问题,解决办法。
    docker 容器中安装cron,却无法启动定时任务
    Elasticsearch:通过 JDBC 使用 SQL 来查询索引 - DBeaver
    风力涡轮机损伤检测图像数据集(400多张图像,VOC标签)
    基于C#的学生选课管理系统
  • 原文地址:https://blog.csdn.net/m0_64210833/article/details/126223302