如何用好MySQL索引？你必须了解这些事！

如何用好MySQL索引？下面本篇文章就来给大家分享一些想要用好MySQL索引，你必须知道的事情，希望对大家有所帮助！ 这一篇文章来聊一聊如何用好MySQL索引。 为了更好地进行解释，我创

    如何用好MySQL索引？下面本篇文章就来给大家分享一些想要用好MySQL索引，你必须知道的事情，希望对大家有所帮助！<p><img src="https://img.mryunwei.com/uploads/2023/04/20230417070858459.jpg"></p>

这一篇文章来聊一聊如何用好MySQL索引。

为了更好地进行解释，我创建了一个存储引擎为InnoDB的表user_innodb，并批量初始化了500W+条数据。包含主键id、姓名字段（name）、性别字段（gender，用0，1表示不同性别）、手机号字段（phone），并为name和phone字段创建了联合索引。

InnoDB使用联合索引查出所有name为蝉沐风的二级索引数据，得到3个主键值：3485，78921，423476；

拿到主键索引进行回表，到聚簇索引中拿到这三条完整的用户记录；

InnoDB把这3条完整的用户记录返回给MySQL的Server层，在Server层过滤出尾号为6606的用户。

如下面两幅图所示，第一幅图表示InnoDB通过3次回表拿到3条完整的用户记录，交给Server层；第二幅图表示Server层经过phone LIKE "%6606"条件的过滤之后找到符合搜索条件的记录，返给客户端。

存储引擎把数据给Server层Server层返回过滤数据

值得我们关注的是，索引的使用是在存储引擎中进行的，而数据记录的比较是在Server层中进行的。现在我们把上述搜索考虑地极端一点，假如数据表中10万条记录都符合name='蝉沐风'的条件，而只有1条符合phone LIKE "%6606"条件，这就意味着，InnoDB需要将99999条无效的记录传输给Server层让其自己筛选，更严重的是，这99999条数据都是通过回表搜索出来的啊！关于回表的代价你已经知道了。

现在引入索引下推。准确来说，应该叫做索引条件下推（Index Condition Pushdown，ICP），就是过滤的动作由下层的存储引擎层通过使用索引来完成，而不需要上推到Server层进行处理。ICP是在MySQL5.6之后完善的功能。

再回顾一下，我们第一步已经通过name = "蝉沐风"在联合索引的叶子节点中找到了符合条件的3条记录，而且phone字段也恰好在联合索引的叶子节点的记录中。这个时候可以直接在联合索引的叶子节点中进行遍历，筛选出尾号为6606的记录，找到主键值为78921的记录，最后只需要进行1次回表操作即可找到符合全部条件的1条记录，返回给Server层。

很明显，使用ICP的方式能有效减少回表的次数。

另外，ICP是默认开启的，对于二级索引，只要能把条件甩给下面的存储引擎，存储引擎就会进行过滤，不需要我们干预。

执行以下SQL语句，并用EXPLAIN查看一下执行计划，此时的执行计划是Using index condition

然后关闭ICP

再次执行查询语句，并用EXPLAIN查看一下执行计划，此时的执行计划是Using where

注：即使满足索引下推的使用条件，查询优化器也未必会使用索引下推，因为可能存在更高效的方式。

由于之前我给name字段创建了索引，导致一直没有使用索引下推，EXPLAIN语句显示使用了name索引，而不是name和phone的联合索引；删除name索引之后，才获得上述截图的效果。大家做实验的时候需要注意。

到目前为止大家应该清楚了索引和回表带来的性能问题，讲这些自然不是为了恐吓大家让大家远离索引，相反，我们要以正确的方式积极拥抱索引，最大限度降低其带来的负面影响，放大其优势。如何用好索引，从两个方面考虑：