索引是帮助数据库进行快速查找的一种有序的数据结构。
数据库索引为什么使用B+树
数据库中索引都放在磁盘中，在进行查找数据的时候应该尽量避免磁盘I/O。
局部性原理与磁盘预读
根据局部性原理，如果当前时刻访问了该值那么该值周围的数据很有可能也会被访问。因此我们在获取磁盘中的数据时，一般都会从该值开始一次性获取后面一页大小4KB的数据。
采用B+树刚好利用这一机制将一个节点的大小设置为一页的整数倍，一般为16K，可以大量的减小磁盘I/O。
B+树特性
B+树的非叶子节点上只存储索引数据，因此相对于B-树来说非叶子节点上可以存储更多的数据，可以减小树高，减小磁盘I/O。
B+将全部数据都放在了叶子节点上，并且是有序的。相当于使用hash表来说对一些排序，区间范围查找更加有效。
数据库引擎
MyIsam
MyIsam只支持表级锁，不支持事务，是非聚簇引擎。
叶子节点中的存放的是地址。根据索引搜索到地址后根据地址去获取数据。
辅助索引与主键索引是一样的都是获取地址值，只是主键索引是唯一的。
InnoDB
InnoDB支持表级锁与行级锁，支持事务，MVCC版本控制，是默认的搜索引擎。是聚簇索引。
InnoDB主键中存放了所有数据，是聚簇索引。并且InnoDB是默认按照主键进行聚集的，所以必须要设置主键。
当没有设置主键时，数据库会搜索唯一的一列自动作为主键，如果每一列都不唯一则在最后新生成一列作为主键。
当使用辅助索引时，在叶子节点上保存的是主键。因此搜索到主键后还要按照主键索引去查找数据，要经过两次索引。
那你能说说回表是什么吗？
答：回表就是先通过数据库索引找到主键Id，然后再通过主键id再进行一次查找。比如select birthday from user where username = ”小明"，先通过username找到小明的id值，然后通过该id值再主键查询到birthday值。
那怎么解决回表问题呢？
答：使用覆盖索引解决，将需要查找的值放到一个索引中，一次查询就查询到了全部值，因此就不要根据主键再次查找了。比如建立birthday与username的索引。
InnoDB为什么要使用整型自增的主键
因为每一次辅助索引都要经过主键索引，如果主键字段太大的话会占用很大的内存空间。
因为InnoDB底层是一个B+树，当使用自增型的主键插入新记录时会比较容易维护B+树。
索引分类
普通索引：一个索引只包含单个列，一个表可以有多个单列索引。
唯一索引：索引列的值必须唯一，但允许有null值。
联合索引：多列值组成一个索引，专门用于组合搜索。
主键索引与唯一索引差别
1.主键是一种约束，而唯一索引就是一种索引。
2.一张表只有一个主键，但可以有多个唯一索引。
3.主键索引不允许有null值，但唯一索引可以允许有null值。
联合索引最左前缀原则
联合索引需遵循最左前缀原则。建立索引：
ALTER TABLE tableName ADD INDEX ('age','name','sex');
建立以下索引判断索引是否生效
A:select * from student where age = 16 and name = '小张'
B:select * from student where name = '小张' and sex = '男'
C:select * from student where name = '小张' and sex = '男' and age = 18
D:select * from student where age > 20 and name = '小张'
E:select * from student where age != 15 and name = '小张'
F:select * from student where age = 15 and name != '小张'
A遵从最左匹配原则，age是在最左边，所以A走索引；
B直接从name开始，没有遵从最左匹配原则，所以不走索引；
C虽然从name开始，但是有索引最左边的age，mysql内部会自动转成where age = '18' and name = '小张' and sex = '男' 这种，所以还是遵从最左匹配原则；
D这个是因为age>20是范围，范围字段会结束索引对范围后面索引字段的使用，所以只有走了age这个索引；
E这个虽然遵循最左匹配原则，但是不走索引，因为!= 不走索引；
F这个只走age索引，不走name索引，原因如上；
索引失效的场景
1.使用NOT的情况：！=，NOT IN，NOT EXIST都会导致索引失效。
2.使用or：使用or的字段无论是否存在索引都会全表扫描
3.不能在索引列上使用相关函数：select * from a where a.age + 1 > 16;
4.数据类型不匹配：select * from a where a.age = '1';age类型为整型，不能用字符串。
5.使用like模糊查询时，在模糊查询中%放在前面。
6.当数据量很少时，如果使用全表扫描更快，则不会使用索引。
7.联合索引并没有按照最左前缀原则。
索引优缺点
优点
1.创建索引可以加快查询速度。
2.创建唯一索引可以保证列的唯一性
3.通过索引列对数据进行排序，可以降低排序的成本。
缺点
1.虽然索引加大了数据的查询速度，但是会降低维护表的速度，因为当插入删除数据时都要更新对应的索引。
2.索引也会占用物理空间。
索引的适用场景与不适用场景
适用场景：
默认主键唯一索引
当需要频繁的对某一字段进行查找，可以建立索引
查询中排序的字段建立索引可以大大降低排序消耗
查询中统计或者分组字段
不适用场景：
表中的数据太少
频繁的对表或者字段进行增删改操作
索引优化
1.对于单键索引，选择针对当前query过滤性最好的索引。
2.对于组合索引，把过滤性最好的字段的索引放在最前面
3.对于组合索引，当需要范围查找时应该把该字段的索引放在最后面
4.规范sql语句，避免索引失效。
唯一索引与普通索引
当更新一个数据页时，如果该数据页在内存中时则会直接更新，如果不在数据页时在不影响数据一致性的情况下会写到change buffer中，避免了磁盘读取，当需要用到该数据页时才会从内存与change buffer中获取。
因为唯一索引要判断唯一性，所以就不能使用change buffer，所以其实就普通索引可以使用。
对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时change buffer的使用效果最好，这种业务模型常见的就是账单类、日志类的系统。反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在change buffer，但之后由于马上要访问这个数据页，会立即触发merge过程。这样随机访问IO的次数不会减少，反而增加了change buffer的维护代价，所以，对于这种业务模式来说，change buffer反而起到了副作用。
