相信大家对mysql的索引都不陌生，不知道大家对于索引是否有足够的关注，因为前单位有专业的DBA，所以对索引的关注较小，我们更多的是考虑到业务，但是在最近找工作的时候才发现，自己对于mysql索引了解的太少，该篇文章主要是介绍mysql的索引。希望能够给大家一点帮助。也帮助我记忆。

索引是帮助大家提供快速检索数据的一种数据结构。

常见的Mysql索引主要有2种数据结构：B+树结构 和 hash结构。常见的InnoDB引擎就是使用的B+树的数据结构。

B+树是一个平衡的多叉树。B+树从根节点到叶子节点的搜索效率基本相当，不会出现大幅波动。

哈希索引采用一定的哈希算法，把键值换成新的哈希值，检索时不需要类似B+树那样从根节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置。

两者的区别：

哈希索引的优势：

• （1）等值查询。哈希索引具有绝对的优势（前提是：没有大量重复键值，如果大量重复键值时，哈希索引的效率很低，因为存在所谓的哈希碰撞问题。）

哈希索引不适用的场景：

• （1） 不支持范围查询
• （2） 不支持索引完成排序
• （3） 不支持联合索引的最左前缀匹配规则

MySQL中，只有HEAP/MEMORY引擎才显示支持哈希索引。而常用的InnoDB引擎中默认使用的是B+树索引，它会实时监控表上索引的使用情况，如果认为建立哈希索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区”建立哈希索引（在InnoDB中默认开启自适应哈希索引），通过观察搜索模式，MySQL会利用index key的前缀建立哈希索引，如果一个表几乎大部分都在缓冲池中，那么建立一个哈希索引能够加快等值查询。

注意：在某些工作负载下，通过哈希索引查找带来的性能提升远大于额外的监控索引搜索情况和保持这个哈希表结构所带来的开销。但某些时候，在负载高的情况下，自适应哈希索引中添加的read/write锁也会带来竞争，比如高并发的join操作。like操作和%的通配符操作也不适用于自适应哈希索引，可能要关闭自适应哈希索引。

unique key unique_username using btree(`user_name`)

这里的using btree 只是显示的指定的使用的索引的方式为b+树，对于innodb来说默认的索引方式也是用b+树，因此，也可以不写。