目录

• 什么是数据库事务？
• 事物的四大特性(ACID)介绍一下?
• 刚才你说原子性是基于日志的Redo/Undo机制，你能说一说Redo/Undo机制吗？
• 之前你还提到事务的隔离级别，你能说一说吗？
• 事务隔离咋实现的？
• 那回滚日志什么时候删？
• 长事务为什么建议不用？
• 你在上面提到MVCC（多版本并发控制），你能说一说原理吗？
• 什么是多版本并发控制呢？
• InnoDB的MVCC实现机制
• 那你知道快照（视图）在MVCC底层是怎么工作的吗？
• 那对于一个快照来说，你直到它在MVCC里要遵循什么规则吗？
• 假如两个事务执行写操作，又怎么保证并发呢？
• 为什么要使用视图？什么是视图？
• 视图有哪些特点？
• 视图的使用场景有哪些？
• 视图的优点/缺点
• 什么是游标？
• 什么是脏读？幻读？不可重复读？
• 如何解决事务的并发问题(脏读，幻读)？
• • 脏读的表现和具体解决并发问题
  • 不可重复读/ 幻读 的表现和具体解决并发问题

什么是数据库事务？

一组sql语句组成的数据库逻辑处理单元，在这组的sql操作中，要么全部执行成功，要么全部执行失败。

事务支持是在引擎层实现的。MySQL 原生的 MyISAM 引擎不支持事务，这也是 MyISAM 被 InnoDB 取代的重要原因之一。

事物的四大特性(ACID)介绍一下?

1.原子性： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；是基于日志的Redo/Undo机制。

2.一致性： 一个事务执行之前和执行之后都必须处于一致性状态。比如a与b账户共有1000块，两人之间转账之后无论成功还是失败，它们的账户总和还是1000。

3.隔离性： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；可用隔离级别解决脏读、幻读、不可重复读问题。隔离越严实，效率越低。

4.持久性： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

刚才你说原子性是基于日志的Redo/Undo机制，你能说一说Redo/Undo机制吗？

Redo/Undo机制比较简单，它们将所有对数据的更新操作都写到日志中。

Redo log用来记录某数据块被修改后的值，可以用来恢复未写入 data file 的已成功事务更新的数据；Undo log是用来记录数据更新前的值，保证数据更新失败能够回滚。

假如数据库在执行的过程中，不小心崩了，可以通过该日志的方式，回滚之前已经执行成功的操作，实现事务的一致性。

例子：假如某个时刻数据库崩溃，在崩溃之前有事务A和事务B在执行，事务A已经提交，而事务B还未提交。当数据库重启进行 crash-recovery 时，就会通过Redo log将已经提交事务的更改写到数据文件，而还没有提交的就通过Undo log进行roll back。

之前你还提到事务的隔离级别，你能说一说吗？

隔离级别，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。

SQL 标准定义了四个隔离级别：
读取未提交： 允许读取尚未提交的数据变更。最低的隔离级别，可能会导致脏读、幻读或不可重复读。
读取已提交： 一个事务提交后，变更才会被看到。可以阻止脏读，但是幻读或不可重复读仍有可能发生。
可重复读： 一个事务执行时看到的数据是一致的，其他事务变更提交也看不见。可以阻止脏读和不可重复读，但幻读仍有可能发生。
可串行化： 做啥都加锁，事务读写冲突时顺序执行。最高的隔离级别，完全服从ACID的隔离级别，也就是说，该级别可以防止脏读、不可重复读以及幻读。

这里需要注意的是：Mysql 默认采用的 REPEATABLE_READ隔离级别Oracle 默认采用的 READ_COMMITTED隔离级别

事务隔离咋实现的？

底层实现采用的是MVCC（多版本并发控制）方式进行实现。每条记录在更新的时候都会同时记录一条回滚操作日志。同一条记录在系统中可以存在多个版本。

那回滚日志什么时候删？

当系统里没有比这个回滚日志更早的 read-view 的时候。

长事务为什么建议不用？

长事务意味着系统存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。

你在上面提到MVCC（多版本并发控制），你能说一说原理吗？

在实现MVCC时用到了一致性视图，用于支持读提交和可重复读的实现。

• 可重复读的隔离级别，只需要在事务开始的时候创建一致性视图，也叫做快照，之后的查询里都共用这个一致性视图，后续的事务对数据的更改是对当前事务是不可见的，这样就实现了可重复读。
• 读提交，每一个语句执行前都会重新计算出一个新的视图，这个也是可重复读和读提交在MVCC实现层面上的区别。

MVCC最大的好处:读不加锁，读写不冲突。在读多写少的应用中，读写不冲突非常重要，极大的增加了系统的并发性。InnoDB使用的是行锁，并且采用了多版本并发控制来提高读操作的性能。

什么是多版本并发控制呢？

其实就是在每一行记录的后面增加了两个隐藏列，记录创建版本号和删除版本号。而每一个事务开启的时候，都会有唯一的递增版本号，被操作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的，对于数据的更新（包括增删改）操作成功，会将这个版本号更新到数据的行中，事务提交成功，将新的版本号更新到此数据行中。这样保证了每个事务操作的数据，都是互不影响，也不存在锁的问题。

InnoDB的MVCC实现机制

MVCC可以认为是行级锁的一个变种，它可以在很多情况下避免加锁操作，因此开销更低。MVCC的实现大都都实现了非阻塞的读操作，写操作也只锁定必要的行。InnoDB的MVCC实现，是通过保存数据在某个时间点的快照来实现的。一个事务，不管其执行多长时间，其内部看到的数据是一致的，也就是事务在执行的过程中不会相互影响。

简述一下MVCC在InnoDB中的实现：

InnoDB的MVCC，通过在每行记录后面保存两个隐藏的列来实现：一个保存了行的创建时间，一个保存行的过期时间（删除时间），当然，这里的时间并不是时间戳，而是系统版本号，每开始一个新的事务，系统版本号就会递增。在RR隔离级别下，MVCC的操作如下：

• select操作：
  InnoDB只查找版本早于（包含等于）当前事务版本的数据行。可以确保事务读取的行，要么是事务开始前就已存在，或者事务自身插入或修改的记录。
  行的删除版本要么未定义，要么大于当前事务版本号。可以确保事务读取的行，在事务开始之前未删除。
• insert操作：将新插入的行保存当前版本号为行版本号。
• delete操作：将删除的行保存当前版本号为删除标识。
• update操作：变为insert和delete操作的组合，insert的行保存当前版本号为行版本号，delete则保存当前版本号到原来的行作为删除标识。

由于旧数据并不真正的删除，所以必须对这些数据进行清理，innodb会开启一个后台线程执行清理工作，具体的规则是将删除版本号小于当前系统版本的行删除，这个过程叫做purge。

那你知道快照（视图）在MVCC底层是怎么工作的吗？

在InnoDB 中每一个事务都有一个自己的事务id，并且是唯一的，递增的 。

对于Mysql中的每一个数据行都有可能存在多个版本，在每次事务更新数据的时候，都会生成一个新的数据版本，并且把自己的数据id赋值给当前版本的row trx_id。

那对于一个快照来说，你直到它在MVCC里要遵循什么规则吗？

对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：

• 1.版本未提交，不可见；

• 2.版本已提交，但是是在视图创建后提交的，不可见；

• 3.版本已提交，而且是在视图创建前提交的，可见。

• InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。

• 而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。

• 也就是说，数据表中的一行记录，其实可能有多个版本 (row)，每个版本有自己的 row trx_id。

假如两个事务执行写操作，又怎么保证并发呢？

假如事务1和事务2都要执行update操作，事务1先update数据行的时候，先回获取行锁，锁定数据，当事务2要进行update操作的时候，也会取获取该数据行的行锁，但是已经被事务1占有，事务2只能wait。

若是事务1长时间没有释放锁，事务2就会出现超时异常 。

为什么要使用视图？什么是视图？

它没有物理结构，作用是事务执行期间用来定义“我能看到什么数据”，提高复杂SQL语句的复用性和表操作的安全性。

MySQL的视图：1. 查询语句虚拟表(view) 2. InnoDB实现MVCC时的一致性读视图。

视图有哪些特点？

• 列可以来自不同的表
• 由实表产生的表虚表
• 建立和删除不影响基本表
• 对视图内容的更新(添加，删除和修改)直接影响实表。
• 当视图来自多个基本表时，不允许添加和删除数据。

视图的使用场景有哪些？

• 保护数据。
• 重用SQL语句；
• 更改数据格式和表示。返回与底层表的表示和格式不同的数据。
• 简化复杂的SQL操作。在编写查询后，可以方便的重用它而不必知道它的基本查询细节；
• 使用表的组成部分而不是整个表；

视图的优点/缺点

优点：

• 查询简单化。视图能简化用户的操作
  数据安全性。视图使用户能以多种角度看待同一数据，能够对机密数据提供
• 安全保护
• 逻辑数据独立性。视图对重构数据库提供了一定程度的逻辑独立性

缺点：

• 性能。数据库必须把视图的查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，数据库也把它变成一个复杂的结合体，需要花费一定的时间。
• 修改限制。当用户试图修改视图的某些行时，数据库必须把它转化为对基本表的某些行的修改。事实上，当从视图中插入或者删除时，情况也是这样。对于简单视图来说，这是很方便的，但是，对于比较复杂的视图，可能是不可修改的。

什么是游标？

游标是系统为用户开设的一个数据缓冲区，存放SQL语句的执行结果，每个游标区都有一个名字。用户可以通过游标逐一获取记录并赋给主变量，交由主语言进一步处理。

什么是脏读？幻读？不可重复读？

脏读：在一个事务处理过程里读取了另一个未提交的事务中的数据。

不可重复读：在对于数据库中的某行记录，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，另一个事务修改了数据并提交了。

幻读：当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行，就像产生幻觉一样，这就是发生了幻读。

如何解决事务的并发问题(脏读，幻读)？

注意：要想解决脏读、不可重复读、幻读等读现象，那么就需要提高事务的隔离级别。但与此同时，事务的隔离级别越高，并发能力也就越低。

为了解决上述问题，数据库通过锁机制解决并发访问的问题。

• 根据锁定对象不同：分为行级锁和表级锁；
• 根据并发事务锁定的关系上看：分为共享锁定和独占锁定，共享锁定会防止独占锁定但允许其他的共享锁定。而独占锁定既防止共享锁定也防止其他独占锁定。为了更改数据，数据库必须在进行更改的行上施加行独占锁定，insert、update、delete和select for update语句都会隐式采用必要的行锁定。

但是直接使用锁机制管理是很复杂的，基于锁机制，数据库给用户提供了不同的事务隔离级别。

脏读的表现和具体解决并发问题

一个事务读取到了另外一个事务没有提交的数据。

详细解释：脏读就是指:当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。

解决：

• 修改时加排他锁，直到事务提交后才释放；

• 读取时加共享锁，读取完释放事务1读取数据时加上共享锁后（这样在事务1读取数据的过程中，其他事务就不会修改该数据），不允许任何事物操作该数据，只能读取，之后1如果有更新操作，那么会转换为排他锁，其他事务更无权参与进来读写，这样就防止了脏读问题。

但是当事务1读取数据过程中，有可能其他事务也读取了该数据，读取完毕后共享锁释放，此时事务1修改数据，修改完毕提交事务，其他事务再次读取数据时候发现数据不一致，就会出现不可重复读问题，所以这样不能够避免不可重复读问题。

不可重复读/ 幻读 的表现和具体解决并发问题

不可重复读：在同一事务中，两次读取同一数据，得到内容不同
幻读：同一事务中，用同样的操作读取两次，得到的记录数不相同
解决：

• 读取数据时加共享锁，写数据时加排他锁，都是事务提交才释放锁。读取时候不允许其他事物修改该数据，不管数据在事务过程中读取多少次，数据都是一致的，避免了不可重复读问题