这类问题在面试里经常被问到，但很多人只背概念，真到实际排查慢查询或者设计索引时，还是不知道怎么用。索引下推（Index Condition Pushdown, ICP）不是个花架子，它直接影响着查询到底是在存储引擎层就过滤掉数据，还是要把一大堆数据捞到Server层再做筛选。这个区别，在数据量大、查询条件复杂的时候，性能差距会非常明显。简单说，索引下推解决的核心问题是：在利用非主键索引（也叫二级索引）进行查询时，如何更早、更有效地利用索引中包含的列来过滤数据，减少不必要的回表操作和Server层的计算负担。如果你正在准备面试，或者在实际工作中遇到了“明明有索引，查询还是慢”的情况，那这篇文章就值得你看。我会从它解决的问题、生效条件、如何判断是否生效，以及实际案例中的优化效果，一步步拆清楚。1. 先搞懂“下推”到底推了什么：从查询执行流程说起要理解索引下推，必须先知道在没有它的时候，MySQL是怎么处理一个带WHERE条件的查询的。我们假设一个最经典的场景：有一张用户表user，在age和city列上建立了一个联合索引idx_age_city。现在要查年龄大于20岁且城市是“北京”的用户。SELECT * FROM user WHERE age 20 AND city = '北京';1.1 没有索引下推（ICP关闭）的执行流程在MySQL 5.6之前，或者手动关闭ICP功能后，它的执行步骤是这样的：存储引擎层：根据索引idx_age_city，定位到第一个满足age 20条件的记录。注意，索引是按照(age, city)排序的。对于age 20这个范围条件，存储引擎会一路向后扫描所有满足age 20的索引条目。回表：每扫描到一条索引记录，不管这条记录的city字段是不是“北京”，存储引擎都会根据索引中存储的主键ID，回到主键索引（聚簇索引）中去查找完整的行数据（这就是“回表”）。Server层过滤：存储引擎把查到的完整行数据返回给MySQL的Server层。Server层再根据WHERE条件中的city = '北京'来过滤这些行。问题出在哪？在第2步，存储引擎明明已经从索引里读到了city字段的值，但它“视而不见”，依然机械地为每一条age 20的记录执行回表。如果满足age 20的记录有10万条，而其中city='北京'的只有100条，那么就会有99900次回表操作是完全浪费的。这些无效的回表带来了大量的随机I/O，是性能的主要瓶颈。1.2 有索引下推（ICP开启）的执行流程索引下推优化，就是把本应在Server层做的部分过滤工作，“下推”到了存储引擎层去做。同样是上面的查询：存储引擎层：根据索引idx_age_city，定位到第一个满足age 20条件的记录。下推过滤：在存储引擎层扫描索引的过程中，同时检查索引中存在的city字段是否等于“北京”。如果city不等于“北京”，那么存储引擎会直接跳过这条索引记录，继续扫描下一条，而不会为它执行回表。回表：只有同时满足age 20ANDcity = '北京'的索引记录，存储引擎才会根据主键ID去回表，取出完整行。Server层确认：将取出的行返回给Server层。因为city条件已经在存储引擎层过滤过了，Server层通常不需要再做额外过滤（除非还有索引中不包含的其他条件）。