目录
一.背景
二.mysql索引的数据结构
三.B+树
四.选择索引
一.背景
我们知道索引既可以帮助查询提升效率，但在DML操作中会有一定的影响，所以我们什么时候该建索引，什么时候不该建。这篇文章通过分析索引的基本原理来帮助我们合理去抉择。
二.mysql索引的数据结构
我们知道Redis使用字典存储键值对、jdk1.8使用数组+链表+红黑树存储hashmap，索引事实上也是可以被设计成键值对存储的结构。
mysql索引选择的存储结构是B+树，主流的关系型数据库都选择的是B+树，如oracle、db2、postgresql等。
为什么mysql不选择字典、红黑树、B树...其他存储结构存储？
因为数据库跟缓存和hashmap有个本质的区别就是数据库本身是一个文件系统。操作系统对内存的读取是纳秒级别而对磁盘的读取是微妙级别，随机访问的情况下前者是后者的10W倍。所以对于磁盘的读取应该尽可能的减少IO次数。而红黑树本身是一颗二叉树深度相对B数太大意味着IO次数会更多(hashmap选择红黑树也是因为删除插入相对B+低是O(logn)，B+树插入最坏情况下是O(N)，综合了查询和修改选择了红黑树)，所以排除红黑树。字典对于单个key的查询时间复杂度是O(1),而对于顺序范围查询则无法满足，所以也不适合(hbase可以对rowkey做范围查询，原因是key的存储是有序的)。
其次根据局部性原理与磁盘预读特性,当一个数据被用到时，其附近的数据也通常会马上被使用,预读的长度一般为页的整倍数 。
最后每次新建结点时，直接申请一个页面的空间，这样可以保证一个结点的大小等于一个页面，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。
下面我们通过学习B+树的原理，来具体看下选择B+树的优点。
三.B+树
InnoDB索引特点
1.InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形.
2.这个索引的key是数据表的主键,这棵树的叶结点data域保存了完整的数据记录(聚簇索引).
3.InnoDB的辅助索引data域存储相应记录主键的值而不是地址
•InnoDB辅助索引展示
辅助索引需要检索两遍：(首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录)
四.选择索引
因为索引虽然加快了查询速度，但索引文件本身占存储空间，同时增加DML负担，对于并发DML场景索引越少越好。
建索引的场景：
1>.慢查询且唯一性高
2>.尽肯能使用递增的列
3>.如果可能,设计索引尽可能的既满足排序,又用于查询行.
不建议建索引。
1>. 没有触发慢查询.
2>. 索引的选择性较低。(比如省份)
3>. 高并发写场景。(读全部使用id获取，根据属性查询操作由搜索引擎处理)
总之，索引越少越好，设计表的时候就应该全部使用id关联。id被设计成无业务自增(无规律会频繁的引起B+数分裂旋转甚至0(N)的重建)
