• MySQL 没有索引下推优化时：

对于联合索引 index(name,age)，我们知 Java 开源项目【ali1024.coding.net/public/P7/Java/git】 道，根据 B+Tree 天然有序的存储特性，LIKE + 右侧模糊匹配虽可以使用到 name 索引，但模糊匹配后得到的结果变成无序，所以后面条件无法再使用到索引，因此需回表提取出 name like '提莫 %'结果集后，再通过普通查询得到 age = 100 的最终结果。

那么 age 字段的索引就这 《一线大厂 Java 面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》开源 么浪费了么？MySQL 想白嫖我服务器资源？

通过参考李海翔老师的流程图，我们可以看出，没有索引下推的情况下，第三步从索引树上取到 name like ‘提莫 %’ 数据后，就回表了，后续再处理 where 剩下的条件，剩下的条件在我们这里也就是 age = 100；相当于多了一次查询过滤操作。

机灵的小伙伴发现，索引字段换个顺序不就得了？聪明~ 这确实是 5.6 之前的一种处理方式，但缺点也很明显，比如字段过滤数据能力降低，没了免费午餐（排序）等~

• MySQL 引入了 ICP 优化后；

如图，在索引内部取到 name 结果之后（步骤 3），步骤 4 就顺便判断了结果中的 age 是否等于 100，对于不等于 100 的记录直接跳过，因此在 index(name,age)这棵索引树中直接匹配到了结果记录，减少了完整查询记录（一条完整元组）读取的个数，此时拿着结果集的 id 去主键索引树中回表查询全部数据，减少了二次查询时间，I/O 次数也会减少。

Cool~

mysql> explain select name from T where name like '提莫 %' and age = 100;

+----+-------------+-------+------------+-------+---------------+------------+---------+------+------+----------+--------------------------+

| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |

+----+-------------+-------+------------+-------+---------------+------------+---------+------+------+----------+--------------------------+

| 1 | SIMPLE | T | NULL | range | index_name | index_name | 72 | NULL | 3 | 25.00 | Using index condition |

+----+-------------+-------+------------+-------+---------------+------------+---------+------+------+----------+--------------------------+

1 row in set, 1 warning (0.00 sec)

总结

如果你选择了 IT 行业并坚定的走下去，这个方向肯定是没有一丝问题的，这是个高薪行业，但是高薪是凭自己的努力学习获取来的，这次我把 P8 大佬用过的一些学习笔记（pdf）都整理在本文中了

《Java 中高级核心知识全面解析》

小米商场项目实战，别再担心面试没有实战项目：