MySQL索引：
简要介绍：一提到索引我们脑海中就必须要有一张索引整体结构的图，最小单元就是索引字段和索引指针(两者加起来也就叫做扇出)，其作用就是为了提高MySQL的查询效率，提高查询效率的根本就是减少磁盘的IO次数达到最终查询的结果，当然不是针对于某一个查询而言，对各种查询场景综合比较的结果比较符合预期。
- 索引的特点：只在叶子节点存储具体数据，非叶子点只存储扇出，索引分为聚簇索引和联合索引，其中聚簇索引一张表中只会存在一个，叶子节点中每个叶子节点都是有序的，页与页之间基本上也是双向链表结构，这个是基于b+数的数据结构实现的。
- 为什么不用hash表，跳表，b数树等其他数据结构，这个还是要基于减少对应的IO次数和每棵树最多能够存储多个索引以及查询的复杂程度，不基于b树来实现对应的结构，是因为b树的非叶子结点也会存储数据，这样就导致根节点维护索引范围比较小，一棵树存储的索引个数比较小，在进行多条数据查询的时候，我们可能还会进行多颗树的加载。而对于b+树我们也许只需要加载一次就行。为什么不用跳表，hash表，是因为我们查询过程中不仅仅只是进行单一查询或者说范围查询，还会有模糊查询，其他几种数据结构可能在简单查询上效率比较高，但是对于复杂一点的查询，性能不一定会优于b+树
- 索引失效的几大场景：like查询，or查询，联合索引，运算查询，不为空，非集合，字段类型转换。前三个基本上都是可以根据索引连续链表的个点进行解释，至于后面几个，基本上都是基于MySQL优化器进行优化之后导致索引失效，在日常SQL优化中，我们要尽量检查对应的SQL出现上述场景，还可以基于表结构进行优化，比如说尽量减少表中出现空值的情况，对于有空值的字段加一个默认的字段。
- 对于辅助索引，需要区分5.6之前和之后的情况
MySQL事务：
事务的特点：ACID,比较难理解的就是一致性，个人觉得就是事务的最终结果是否符合客观事实，比如转账业务，不可能出现一个人与另一个人转完账之后出现转账方的账户为负的，这就违背了事务的一致性。 MVCC:多版本并发控制，表示在多线程环境下对数据读取的最终一致性锁，通过MVCC实现事务的不同隔离级别。其中read uncommit和序列化不会依赖MVCC。对于读已提交和可重复读，不会涉及到MVCC所以只有read commit和repeatable支持MVCC,而MVCC底层是通过InnoDB底层undo.log和read实现的。至于read uncommit目前没有什么太多的解释，序列化则是通过对应的锁实现的，序列化则是保证对应的读和写的原子性，不会出现数据不一致的情况，其底层是通过MySQL的锁实现的。 MySQL锁：按照标准来说，MySQL锁分为共享锁和排他锁，类似于AQS中的共享和排他，只不过这里针对的是事务，锁一共分为单行锁，间隙锁以及next_key lock,单行锁表示的是锁定一条记录，间隙锁表示的是锁定多行范围但不包括范围的本身，next_key lock表示的是锁定一个范围，但可以包含范围的本身，InnoDB默认是使用next_key Lock MySQL日志：不熟，先放着
