什么是数据库事务？

一组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（多版本并发控制）和通过undo log版本链和read-view进行实现。每条记录在更新的时候都会同时记录一条回滚操作日志。同一条记录在系统中可以存在多个版本。

那回滚日志什么时候删？

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

长事务为什么建议不用？

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

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

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

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

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

谈谈你对MVCC的理解

我觉得可以从数据库的三种并发场景来说：

• 第一种是读和读的并发，就是两个线程A和B同时进行读操作，这种情况不会产生任何并发问题。
• 第一种是读和写的并发，就是两个线程A和B同一时刻分别进行读和写操作，这种情况可能会对数据库的数据造成以下问题：
  
  第一个是事务隔离性问题。
  
  第二个是会出现脏读、幻读、不可重复读的问题。
• 第三种就是写和写的并发，就是两个线程A和B同时进行写操作，这种情况可能会造成更新丢失问题。
  
  而MVCC就是为了解决事务操作中并发安全问题的无锁并发控制技术。它是通过数据库中的隐式字段-undo日志-readView来实现的，它主要用来解决三个问题：
  
  第一个、通过MVCC可以解决读写并发阻塞的问题，从而提高数据库的并发处理能力。
  
  第二个是MVCC采用的是乐观锁的方式实现，降低了死锁的概率。
  
  第三个是解决了一致性读的问题，也就是事务启动的时候根据某个条件去读取数据，直到事务结束的时候再去执行相同的条件，还是读到同一份数据，不会发生变化。

而我们在使用MVCC的时候一般是根据业务场景来选择组合搭配乐观锁或者悲观锁，这俩组合中MVCC用来解决读写冲突，乐观锁和悲观锁用来解决写和写的冲突。从而最大程度地提高的数据库的并发性能。

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

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

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。

每个事务对要拷贝一个视图吗？

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。

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

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

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

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

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

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

视图有哪些特点？

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

视图的使用场景有哪些？

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

视图的优点/缺点

优点

：

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

缺点

：

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

什么是游标？

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