索引下推（icp）通过将部分where条件过滤提前至存储引擎层，在遍历二级索引时直接利用索引列值筛除不满足条件的记录，从而减少无效回表——回表即根据索引中主键值去聚簇索引读取完整行数据，涉及随机io；无icp时，所有索引匹配记录均需回表后再由server层过滤，造成大量冗余io；icp仅对索引包含字段且支持索引内计算的条件（如等值、范围、前缀like）生效，执行计划出现“using index condition”即表明启用。
索引下推（ICP）减少回表次数，核心在于把原本在 Server 层做的部分条件过滤，提前挪到存储引擎层，在遍历索引时就筛掉不满足的记录，避免为这些记录执行后续的回表操作。
回表动作本身要做什么
使用二级索引查询时，存储引擎先在索引 B+ 树上找到匹配索引键的记录。每条索引记录里只存了索引列值 + 主键值（比如 age=25, name='张三', id=101），不包含整行数据。要返回 SELECT * 或访问非索引列，就必须拿着这个 id 去聚簇索引（主键索引）里查完整行——这就是一次回表，涉及一次随机 IO（或至少一次额外页读取）。
没有 ICP 时，回表是怎么被浪费的
- 假设联合索引是 (age, name)，查询 WHERE age > 18 AND name LIKE '%李%'
- 存储引擎只用 age > 18 定位索引范围，可能扫出 500 条索引记录
- 不管 name 是否匹配，它都把这 500 条记录的主键全交给 Server 层
- Server 层再逐条拿主键回表，取出行后判断 name LIKE '%李%'，最终可能只有 3 条符合
- 等于白做了 497 次回表
ICP 怎么省掉这 497 次
- 存储引擎在遍历索引过程中，每读到一条索引记录（比如 age=22, name='王五', id=205），就当场用 name LIKE '%李%' 判断
- 发现不匹配，直接跳过，不拿 id=205 去回表
- 只对真正可能满足全部条件的索引记录（如 name='李四'）才执行回表
- 最终可能只回表 3 次，而不是 500 次
哪些条件能被下推
必须满足两个前提：
- 条件字段必须出现在当前使用的二级索引中（例如用了 (age, name) 索引，age = 25 和 name LIKE '张%' 都可下推；但 address = '北京' 不行）
- 条件类型支持索引内计算（比如等值、范围、LIKE 前缀匹配；但 UPPER(name) = 'ZHANG' 或 name IS NULL 通常不能下推）
执行计划中看到 Extra: Using index condition 就说明 ICP 生效了。
