start transaction
sql1 sql2
commit
执行过程分析
为了提升性能，不会每次提交数据都写入磁盘。
事务提交的数据先写入缓冲池，然后使用后台线程来更新缓存和硬盘一致性。
如果没来得及同步，则通过redo log日志恢复一致性。
事务提交了一半数据，还没来得及提交另一半，则通过undo log回滚数据。

3.mysql日志详解？

为什么不用一个日志？
mysql原来没有InnoDB引擎，InnoDB引擎是专门为了恢复崩溃数据的。
为什么redolog要引入prepare和commit状态？
如果不引入，redolog写完后未提交给binlog前系统崩溃，则发生数据不一致。
引入后，崩溃后发现redolog是prepare状态，那么就回滚事务。

4.mysql的索引功能详解？

索引的数据结构需要满足什么？
空间局部访问性原理。
减少IO次数。
能够实现顺序查找。
hash表
数组+链地址
平衡二叉树
二叉树
B树
索引和数据都在树中。平衡多叉树+每个节点有多个子节点
B+树
关键字只存储在叶子节点，非叶子结点不存储data，所有叶子节点都用链表相连。
为什么不用hash表结构呢？
因为Hash表结构不支持顺序和范围查询。
为什么不用平衡二叉树呢？
因为平衡二叉树每个节点一次IO过度浪费资源，且看似很近的数据存储离得很远，满足不了空间局部访问原理，实现不了顺序查找。（树的高度为IO次数）
为什么不用B树呢？
空间局部性原理无法更好的利用。
为什么用B+树呢？
由于节点不存储数据，故索引存储的范围更大更精确。即B+树相对于B树同样的IO能获得更多的索引即更精确的数据。
由于B+树有链表连接叶子节点故可以实现空间局部性原理。
B+树的不同使用
聚簇索引：InnoDB引擎。叶子节点直接存放的是数据。
优点：速度快
缺点：依赖于有序数据，更新代价大
非聚簇索引：MyISM引擎。叶子节点存放数据记录地址（数据文件和索引文件分离）。
优点：更新代价小。
缺点：依赖于有序数据，二次查询（即查到记录地址还需再去查文件）。

CURD操作到达执行器。
判断BufferPool中是否有该数据（没有则从磁盘中调入，有则直接更改BufferPool的数据）。
事务执行过程中，会记录更改过程到 bin log buffer 。
redo log buffer记录更新操作。
如果事务提交了
（mysql默认配置事务自动提交）
redo log buffer的更新操作进入prepare状态
同时告诉执行器 bin log buffer执行write操作。
默认参数为0 只执行write操作prepare状态
参数为1 执行write + fsyc
然后redo log buffer 执行write + fsyc操作。
默认参数为1 执行write + fsyc操作
参数为0 不执行（等待后台线程一秒后自动write操作）
参数为2 write

进行更新操作前，都会记录一条undo buffer（相反操作，如果是delete 则是add，如果是add，则是delete），然后undo buffer会持久化到 undo log文件中
事务提交了（利用binlog和redolog），则undo log日志删除，事务未提交而回滚，只需要执行undo log日志的内容即可。
undo log会持久化到磁盘上，如果数据库宕机，那么数据库可以通过查undo log回滚未完成的事务。
注意点：
优点：
undo log会先于数据持久化到磁盘上，即数据持久化到磁盘上，此时undo log一定已经在磁盘中了。这样能够保证事务的原子性，即如果mysql挂了，则可以通过undo log来回滚事务。
缺点：
每个事务提交前将undo log写入磁盘，这样会导致大量的磁盘IO，因此性能较差。