MySQL让索引更高效的方法是什么？

数据库系列更新到现在我想大家对所有的概念都已有个大概认识了，这周我在看评论的时候我发现有个网友的提问我觉得很有意思：如何设计一个索引？你们都是怎么设计索引的？怎么

    数据库系列更新到现在我想大家对所有的概念都已有个大概认识了，这周我在看评论的时候我发现有个网友的提问我觉得很有意思：如何设计一个索引？你们都是怎么设计索引的？怎么设计更高效？

前言

我们知道，索引是一个基于链表实现的树状Tree结构，能够快速的检索数据，目前几乎所RDBMS数据库都实现了索引特性，比如MySQL的B+Tree索引，MongoDB的BTree索引等。

在业务开发过程中，索引设计高效与否决定了接口对应SQL的执行效率，高效的索引可以降低接口的Response Time，同时还可以降低成本，我们要现实的目标是：索引设计->降低接口响应时间->降低服务器配置->降低成本，最终要落实到成本上来，因为老板最关心的是成本。

今天就跟大家聊聊MySQL中的索引以及如何设计索引，使用索引才能提降低接口的RT，提高用户体检。

MySQL中的索引

MySQL中的InnoDB引擎使用B+Tree结构来存储索引，可以尽量减少数据查询时磁盘IO次数，同时树的高度直接影响了查询的性能，一般树的高度维持在 3~4 层。

B+Tree由三部分组成：根root、枝branch以及Leaf叶子，其中root和branch不存储数据，只存储指针地址，数据全部存储在Leaf Node，同时Leaf Node之间用双向链表链接，结构如下：

从上面可以看到，每个Leaf Node是三部分组成的，即前驱指针p_prev，数据data以及后继指针p_next，同时数据data是有序的，默认是升序ASC，分布在B+tree右边的键值总是大于左边的，同时从root到每个Leaf的距离是相等的，也就是访问任何一个Leaf Node需要的IO是一样的，即索引树的高度Level + 1次IO操作。

我们可以将MySQL中的索引可以看成一张小表，占用磁盘空间，创建索引的过程其实就是按照索引列排序的过程，先在sort_buffer_size进行排序，如果排序的数据量大，sort_buffer_size容量不下，就需要通过临时文件来排序，最重要的是通过索引可以避免排序操作（distinct，group by，order by）。

聚集索引

MySQL中的表是IOT（Index Organization Table，索引组织表)，数据按照主键id顺序存储（逻辑上是连续，物理上不连续），而且主键id是聚集索引（clustered index），存储着整行数据，如果没有显示的指定主键，MySQL会将所有的列组合起来构造一个row_id作为primary key，例如表users(id, user_id, user_name, phone, primary key(id))，id是聚集索引，存储了id, user_id, user_name, phone整行的数据。

辅助索引

辅助索引也称为二级索引，索引中除了存储索引列外，还存储了主键id，对于user_name的索引idx_user_name(user_name)而言，其实等价于idx_user_name(user_name, id)，MySQL会自动在辅助索引的最后添加上主键id，熟悉Oracle数据库的都知道，索引里除了索引列还存储了row_id（代表数据的物理位置，由四部分组成：对象编号+数据文件号+数据块号+数据行号），我们在创建辅助索引也可以显示添加主键id。