一、MySQL的索引系统怎么设计的？
- 索引作用：加快数据访问，提高查询效率
- 慢的原因，从磁盘读取效率低，所以要减少IO次数。
- 索引的数据格式是什么？K:字段值，V：文件名称、偏移量、长度，故随着数据文件变多，索引文件也变大。
- 存储K-V格式的数据结构？哈希表？ 二叉树？红黑树？B树？B+树？那么一口气可以读全部的索引到内存吗？答案是不能这么做，只能分块读取。
哈希表为什么不行？
- 适用哈希表的意义是为了让数据尽可能散列，因此使用哈希表的时候尽可能使用合适哈希算法，避免哈希碰撞和哈希冲突。
- 哈希表存储的数据是无序的，当需要进行范围查询的时候只能挨个遍历，效率低。
- mysql的memory存储引擎支持哈希索引，innodb存储引擎自适应hash。
二叉树，BST 、ALV树、红黑树为啥不行？（特性：两个节点、有序、平衡）。二叉树满的情况下，想存储更多数据，只能增加树的高度->IO次数高。
磁盘预读：内存跟磁盘数据交互的时候，基本单位是页，叫做datapage，页的大小跟操作系统有关，一般是4k或8k，在进行数据读取的时候一般是页的整数倍。一个4k 尽可能存储更多的数据->多叉树(有序、平衡)->B树 。
一个节点有什么？(key、行数据、子节点指针)。为了让节点产生存储更多的索引，做法是非叶子节点不存储数据了，只在叶子节点存放数据，并且用双向链表连接起来，这就是 B+树，B+树一般是多少层？一般情况下3-4层足以支持千万级别的数据量。
二、聚簇索引与非聚簇索引
聚簇索引：innodb存储引擎中，数据在进行插入的时候，数据必须与一个索引列绑定在一起，主键->唯一索引->6字节的rowid绑定。
数据跟索引放在一起是聚簇索引。
数据跟索引分开存储是非聚簇索引。
mysiam只有非聚簇索引。
innodb支持以上两种方式。
二级索引：用的是非聚簇索引 存储结构，每一个索引都是一个B+树，还是所有的索引公用一颗B+树？答案是独立的，一个表中存在多颗B+树。
表中的数据存储几份?一份，其他的非聚簇索引的叶子节点的存储的聚簇索引的key值。
联合索引(复合索引)：需要多个列共同组成一个索引字段。
三、索引优化要注意什么？
1、选择字段小的索引。
2、满足业务系统的前提下，尽可能选择自增索引。
3、索引字段尽可能不要为null。
4、选择索引的时候索引的基数尽可能要大。 distinct col /count >= 80% 。
5、索引不是越多越好。
6、尽量避免索引失效。
7、索引字段尽可能不要频繁修改。
索引失效的情况：
- like查询的左边不要加%
- 索引字段不要进行任何表达式操作
- 不要进行函数计算
- 不要进行隐式的类型转换
- 组合索引在使用时要遵循最左匹配原则
- in 或者 or 在很多情况下会导致索引失效，但是要根据实际情况进行判断。
回表：在辅助索引中查找到主键key，在主键索引进行查找结果。回表的效率比较低。
索引覆盖：查询的字段命中了索引。
最左匹配原则：针对组合索引，在查询的时候必须从左到右匹配。
索引下推：select * from table name =? and age =?; 没有索引下推时，先会根据name的值从存储引擎中拿到符合条件的数据，然后在server中对age进行数据过滤。有了索引下推之后，直接根据name和age从存储引擎中筛选对应的数据，返回给server。
四、索引优化
1、覆盖索引，减少回表，此时将所有的查询字段和条件组成了组合索引，达到了优化的效果。
