什么是数据库事务？事物的四大特性(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（多版本并发控制）和通过undo log版本链和read-view进行实现。每条记录在更新的时候都会同时记录一条回滚操作日志。同一条记录在系统中可以存在多个版本。
那回滚日志什么时候删？
当系统里没有比这个回滚日志更早的 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。
每个事务对要拷贝一个视图吗？
在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。
假如两个事务执行写操作，又怎么保证并发呢？
假如事务1和事务2都要执行update操作，事务1先update数据行的时候，先回获取行锁，锁定数据，当事务2要进行update操作的时候，也会取获取该数据行的行锁，但是已经被事务1占有，事务2只能wait。
若是事务1长时间没有释放锁，事务2就会出现超时异常 。
为什么要使用视图？什么是视图？
它没有物理结构，作用是事务执行期间用来定义“我能看到什么数据”，提高复杂SQL语句的复用性和表操作的安全性。
MySQL的视图：1、查询语句虚拟表(view) 2、InnoDB实现MVCC时的一致性读视图。
视图有哪些特点？
列可以来自不同的表由实表产生的虚表建立和删除不影响基本表对视图内容的更新(添加，删除和修改)直接影响实表。当视图来自多个基本表时，不允许添加和删除数据。
视图的使用场景有哪些？
保护数据。重用SQL语句；更改数据格式和表示。返回与底层表的表示和格式不同的数据。简化复杂的SQL操作。在编写查询后，可以方便的重用它而不必知道它的基本查询细节；使用表的组成部分而不是整个表；
视图的优点/缺点
优点：
查询简单化。视图能简化用户的操作数据安全性。视图使用户能以多种角度看待同一数据，能够对机密数据提供安全保护逻辑数据独立性。视图对重构数据库提供了一定程度的逻辑独立性
缺点：
性能。数据库必须把视图的查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，数据库也把它变成一个复杂的结合体，需要花费一定的时间。修改限制。当用户试图修改视图的某些行时，数据库必须把它转化为对基本表的某些行的修改。事实上，当从视图中插入或者删除时，情况也是这样。对于简单视图来说，这是很方便的，但是，对于比较复杂的视图，可能是不可修改的。
什么是游标？
游标是系统为用户开设的一个数据缓冲区，存放SQL语句的执行结果，每个游标区都有一个名字。用户可以通过游标逐一获取记录并赋给主变量，交由主语言进一步处理。