面试题概览：
面试官：什么是数据库的事务，说说你对事务个性的了解？
数据库事务是数据库治理系统口头环节中的一个逻辑单位，由一个有限的数据库操作序列构成。这些操作要么所有口头成功，要么所有不口头，是一个无法宰割的上班单位。
关于事务的个性，可以从以下几个方面来了解：
一、原子性（Atomicity）
原子性是指事务是一个无法宰割的上班单位，事务中的操作要么所有成功，要么所有不成功。在数据库操作中，假设事务中的某个操作失败，则整个事务会回滚到事务开局前的形态。这种个性经过数据库的Undo机制来成功，即在事务口头环节中，假设出现失误或用户口头ROLLBACK语句，系统可以回滚到事务开局前的形态。
二、隔离性（Isolation）
隔离性是指并发口头的事务之间相互隔离，不准许一个事务的口头结果影响其余事务的口头。这种个性防止了多个事务并发口头时或者出现的数据不分歧疑问。数据库系统通常经过锁和其余并发控制技术（如MVCC）来成功隔离性。体现方式是，当一个事务正在对某个数据启动操作时，其余事务不能对该数据启动并发修正，以防止数据不分歧的疑问出现。
三、耐久性（Durability）
耐久性是指一旦事务提交，它对数据库中数据的扭转就是终身性的，即使在系统解体后，事务的修正结果也不会失落。这种个性经过数据库的Redo机制来成功。当事务提交后，系统将把事务的一切操作写入到日志文件中，以便在系统复原后经过Redo日志从新口头这些操作，保障数据的分歧性。
四、分歧性（Consistency）
分歧性是指事务必定将数据库从一种分歧形态转换到另一种分歧形态。这么说有点形象，我团体的详细了解是：分歧性体如今两点。
同一个表的在本次事务中有咨询的多条记载的形态要对的上，比如转账前后两个账户的金额总和应该不变（两条同一张表的update语句）。
不同表在本次事务中有咨询的多条记载的形态要对的上，比如生产后参与用户积分并缩小用户金额，那么用户的金额缩小后，不能由于缺点造成用户积分没参与（两条不同表的update语句）。
上述四个特点中，分歧性是事务的最终目的。只需其余三个个性都满足了，那么分歧性人造而然也就会满足，也就是说原子性，隔离性和耐久性是要求作出的致力，分歧性是我们想要的结果。
面试官：原子性——说说看Mysql是如何经过undo日志成功原子性？
首先是MySQL如何经过undo日志成功原子性的详细解释：
一、undo日志的作用
undo日志，也被称为回滚日志，是MySQL中用于记载事务在口头环节中对数据的修正前的形态（即旧值）的一种日志。当事务要求回滚时，MySQL可以应用undo日志将数据复原到事务开局前的形态，从而保障事务的原子性。
undo日志分为3类：
上方是undo日志的详细结构，其余的不用关注，重点关注图中倒数第二格的 <len, value>，外面蕴含增删改操作前的详细字段和值，数据库回滚就是经过这些字段和值来启动的。
二、成功原子性的环节
(1) 事务开局：
(2) 记载undo日志：
(3) 事务提交或回滚：
三、undo日志的详细成功
1.undo日志的存储：
undo日志被存储在InnoDB存储引擎的公用页面中，这些页面被称为undo页面。
undo页分为两种：insert类型的undo日志（外面只放insert类型的undo日志） 和 update类型的undo日志（放update和delete类型的undo日志）。
undo页面以链表的方式组织，每个undo页面都蕴含了多条undo日志，Innodb会为每一个事务一条或两条undo链表（假设该事务同时蕴含增删改操作就会生成两条undo链表）。
之所以要将同一个事务发生的undo日志组织在同一个链表而非一切事务的undo日志组织成一个链表也是为了回滚时可以按事务的维度找到只和身手务关系的undo日志启动回滚。
两种不同类型的undo日志页区分用 insert undo 链表 和 update undo 链表治理。
把 undo 日志分红 2 个大类是由于insert类型的 undo 日志在事务提交后可以间接删除，而其余类型的 undo 日志还要求为 MVCC（多版本并发控制）服务，不能在事务提交后马上删除。
2.回滚操作：
当事务要求回滚时，MySQL会沿着undo日志链表，依照与事务口头相反的顺序，逐条运行undo日志中的消息，将数据复原到事务开局前的形态。
面试官：耐久性——Mysql的InnoDB是如何成功数据耐久化的？
说到数据库耐久化就绕不开 WAL 机制 和 redo日志。
一、WAL和redo log的基本概念
WAL是一种数据安保写入机制，其**理想是在事务启动修正之前，先将修正操作记载到日志中，而后再将修正运行到数据库中。这样做的好处是，即使系统解体或断电，也可以经过日志来复原数据，保障数据的耐久性和分歧性。
redo日志是InnoDB存储引擎独有的物理日志，记载了数据操作的细节，包括事务开局和完结的标志、修正的数据页和对应的操作等。它重要用于缺点复原，当数据库出现异常封锁或解体时，InnoDB可以经过redo日志来复原数据。
redo日志以固定大小的多个文件（如ib_logfile0、ib_logfile1）构成的文件组的方式存在，是一个可笼罩的循环日志。InnoDB 的 redo log 是固定大小的，比如可以性能为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记载 4GB 的操作。从头开局写，写到末尾就又回到扫尾循环写，如上方这个图所示。
write pos 是记载的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件扫尾。checkpoint 标志了日志中曾经刷盘成功的数据所对应的redo日志数据。
write pos 和 checkpoint 之间的是redo日志上可被新的事务的增删改操作所笼罩的部分，可以用来记载新的操作。假设 write pos 追上 checkpoint，示意redo日志满了，这时刻不能再口头新的降级，得停上去将Buffer Pool中的脏页刷盘，把 checkpoint 推动一下才干继续写redo日志。
有了 redo log，InnoDB 就可以保障即使数据库出现异常重启，之前提交的记载都不会失落，这个才干称为 crash-safe。
下图是一条便捷redo日志的数据结构：
其中 space ID 示意本修正所对应的数据页所在的表空间，page number是所修正的页号，offer是所修正的数据在页中的偏移量。经过这3个消息，就可以在缺点复原时找到要复原的数据页和数据页中的详细位置。
二、redolog写入的详细环节
(1) 事务开局：
当一个事务开局时，MySQL会为该事务调配一个惟一的事务ID，并将该事务的关系消息存储在内存中的事务控制块（Transaction Control Block, TCB）中。
(2) 修正操作记载到redo log buffer：
在事务口头环节中，一切的修正操作（如拔出、降级、删除等）都会被写入redo log缓冲区（redo log buffer）。redo log buffer是一个内存缓冲区，用于暂存待写入redo log的修正操作。
(3) 事务提交和redo log刷盘：
当事务提交时，MySQL会将该事务的一切修正操作依照顺序写入redo log文件中。这个环节称为redo log的刷新（flush）。
要求留意的是，在事务提交之前，MySQL并不会立即将redo log buffer中的修正操作耐久化到磁盘上的redo log文件中。而是会期待一个适合的机遇来启动耐久化操作。基于innodb_flush_log_at_trx_commit性能参数的刷盘战略如下。
innodb_flush_log_at_trx_commit：三、复原数据的详细环节
(1) 启动InnoDB：当MySQL服务重启时，InnoDB存储引擎会开局启动。
(2) 定位checkpoint：InnoDB会经过redo日志找到最近一次性checkpoint的位置。checkpoint消息保留在日志文件的开部分分，包括checkpoint号、checkpoint lsn（记载了发生该checkpoint时flush的LSN，确保在该LSN前面的数据页都曾经落盘，不再要求经过redo log启动复原）和checkpoint offset（记载了该checkpoint发生时，redo log在ib_logfile中的偏移量）。
(3) 失掉并解析redo日志：
从checkpoint相对应的位置开局，InnoDB会失掉要求重做的日志。
接着，InnoDB会解析失掉的日志，并将其保留到一个哈希表中。哈希表以（space，offset）为键，存储了redo日志的消息。
(4) 数据复原：
InnoDB会遍历哈希表中的redo日志消息。
关于每条redo日志，InnoDB会依据（space ID，page number，offset）读取指定页面，并启动日志笼罩，即依据redo日志中的记载来复原数据页的内容。
面试官：数据库并发事务或者会出现什么疑问，以及该如何处置？
一、数据分歧性疑问
1.脏读
一个事务读取了另一个事务未提交的数据，这些数据或者会被回滚，从而造成读取到有效数据。
以下是一个详细的脏读示例：
事务A首先口头了一个select操作，从account表中读取了id=1的账户的money值，此时失掉的mnotallow=0。
接着，事务A尝试口头一个update操作，将id=1的账户的money值设置为2000。另一个事务（事务B）修正了该账户的money值，并且这个修正还未提交。
假设事务A最终不提交其修正，那么事务B读取到的mnotallow=2000就是一个“脏读”，即读取到了其余事务还未提交的数据。
事务B基于这个“脏读”的数据启动业务处置或者会造成疑问，例如修正了其余表里的数据，最终数据不分歧。
为了防止脏读，数据库系统通常实施更高的事务隔离级别，如READ COMMITTED或更高，以确保事务只能读取到已提交的数据。
2.无法重复读
一个事务在两次读取同一数据时，因其余事务的提交造本钱事务数据出现了变动，从而两次读取无法取得分歧的结果。无法重复读会在事务要求基于屡次读取结果启动复杂计算时发生影响。
以下是一个无法重复读示例：
为了防止无法重复读，数据库系统要求实施适当的事务隔离级别（如READ COMMITTED或更高）或经常使用其余并发控制机制来确保事务在读取数据时不会遭到其余事务修负数据的影响。
在READ COMMITTED隔离级别下，事务只能读取到其余事务曾经提交的修正，从而防止了脏读和无法重复读（但幻读依然或者出现）。而在更高的隔离级别（如REPEATABLE READ或SERIALIZABLE）下，数据库系统会进一步限度并发操作，以缩小或消弭幻读现象，但会严重影响并发性能。
3.幻读
一个事务（经过条件）读取多条记载后，因其余事务的拔出或删除，造成再次读取时取得的记载集出现变动。幻读疑问通常出当初拔出或删除操作频繁的场景中。
以下是一个幻读的详细示例：
再举一个关于幻读的例子增强一下大家对幻读的了解：
假定有一个银行系统，它有一个账户表（accounts），用于记载客户的账户余额和其余关系消息。如今，有两个事务T1和T2同时运转，并且它们都对满足某个条件的账户汇合启动操作。
(1) 事务T1：
(2) 事务T2：
(3) 事务T1（继续）：
(4) 结果：事务T1在处置账户汇合时，由于幻读现象，它必定处置一个额外的账户D，这或者造成一些异常的行为或失误。例如，假设事务T1的指标是向所缺乏额大于500元的老账户发送一条通知，那么由于幻读现象，新账户D也会收到这条通知。
为了防止幻读，数据库系统要求实施更高的事务隔离级别（如SERIALIZABLE）或经常使用其余并发控制机制（如锁机制或MVCC）来确保事务在读取数据时不会遭到其余事务拔出或删除数据的影响。
或者得面试官追问：无法重复度和幻读看上去方式上都是两次读取的结果不同，那么无法重复读和幻读的区别是什么？
(1) 出现场景不同：
(2) 关注点不同：
并发事务除了出现数据分歧性疑问之外，还或者存在其余疑问（如死锁和性能降高等）。
二、死锁
死锁是指两个或多个事务在口头环节中，由于相互持有对方所要求的资源而堕入有限期待的形态。死锁会造成系统资源无法有效应用，严重时或者会使系统堕入瘫痪。经常出现的死锁场景包括两个事务相互期待对方监禁锁，以及多个事务循环期待。
三、性能降低
并发事务增多会参与系统的CPU、内存和I/O负载，影响全体性能。详细体现为：
说到事务并发就不得不先说数据库的隔离级别。事务的隔离级别是数据库中用于控制并发事务间相互影响的机制。
以下是关于事务隔离级别的详细解释以及选用倡导：
事务隔离级别的类型
(1) 读未提交（READ UNCOMMITTED）：
(2) 读提交（READ COMMITTED）：
(3) 可重复读（REPEATABLE READ）：
(4) 序列化（SERIALIZABLE）：
面试官：知道什么是快照读吗，它是用来处置什么疑问的？
(上方的内容或者有点长，宿愿大家能耐烦看完，毕竟面试加分的实质就是答露面试官所问的这个疑问关系的但没有问进去的点)。
快照读（Snapshot Read）是数据库事务处置中的一种读取数据的方式，它确保事务在读取数据时看到的是数据在某个时期点（即事务开局时）的形态，就像拍摄了一张数据在那个时期点的“快照”一样。这种读取方式不会遭到其余并发事务的影响，即使其余事务在读取环节中对数据启动了修正，快照读依然能够读取到事务开局时的数据版本。
快照读的重要特点是：
在MySQL等数据库系统中，快照读通常是经过多版本并发控制（MVCC，Multi-Version Concurrency Control）来成功的。
MVCC是数据库治理系统中用于成功并发控制的一种方法。经过保养数据的多个版原本成功并发控制。
在MVCC中，每个数据项都有多个版本，每个版本都记载了一个时期点或事务ID，示意该版本被创立或修正的时期。当一个事务读取数据时，它会读取一个特定时期点的快照，这个快照蕴含了在该时期点之前提交的一切事务的结果。经过这种方式，事务可以看到一个分歧的视图，而不受其余事务的影响。
详细来说，MVCC的成功通常依赖于以下几个关键组件：
一、Undo Log
定义：Undo Log是数据库中用于记载数据修正历史的日志。当事务启动降级或删除操作时，数据库会生成相应的Undo Log，以便在要求时能够回滚到之前的版本。
在MVCC中，Undo Log不只用于事务回滚，还用于保养版本链，一条undo日志会作为版本链中的一个节点，节点之间经过undo日志的回滚指针衔接。
当事务启动降级或删除操作时，数据库会生成一条undo日志作为新的数据版本，并经过undo日志的回滚指针将新旧版本（旧的undo日志）衔接起来，构成版本链。
二、版本链
定义：版本链是指每个数据项都保养一个记载其修正历史的链表。链表中的每个节点代表数据项的一个版本，这里的“一个版本”就是一条undo日志，包括历史记载的数据内容、修正时期戳或事务ID等消息。
成功：在数据库中，每个数据行都会有一个暗藏的回滚指针（roll_pointer）字段，该字段指向该行的上一个版本（假设存在的话）。这样，经过回滚指针，可以将各个版本衔接起来，构成一个版本链。
下图出现了两个事务对数据表修正环节中生成版本链的环节。
假定一开局hero.name ="刘备"。那么版本链如下：
三、读视图（Read View）
定义：读视图是数据库在特定时辰为某个事务创立的一个快照，该快照蕴含了在该时辰一切未提交事务的消息。
成功：读视图通常蕴含以下关键消息：
作用：读视图用于判别哪些数据版本对事务是可见的。详细来说，当一个事务读取数据时，它会依据读视图中的消息，在版本链中查找满足条件的版本。
四、MVCC的读操作成功
当事务启动读操作时，数据库会依据读视图和版本链来判别应该读取哪个版本的数据。详细来说，数据库会依照以下步骤启动读操作：
五、MVCC处置的疑问
MVCC重要处置了数据库在高并发环境下的读写抵触疑问，以及数据分歧性疑问。详细来说，它处置了以下几个方面的疑问：
（面试官或者得追问：MVCC的缺陷）
保养MVCC并不是没有老本的，上方是MVCC所带来的疑问：