MySQL索引下推（ICP）通过将部分WHERE条件判断下推至InnoDB引擎层，在二级索引遍历时提前过滤不满足条件的项，从而减少回表次数；其生效需满足使用二级索引且含可下推的索引列条件，可通过EXPLAIN中Extra字段是否出现“Using index condition”确认。
MySQL索引下推（ICP）能减少回表次数，是因为它把部分WHERE条件的判断从Server层“挪”到了InnoDB存储引擎层，在遍历二级索引时就直接筛掉不满足条件的索引项，只让真正可能命中的记录才去回表。
ICP生效的前提：必须用到二级索引，且WHERE中有可下推的索引列条件
ICP不会在聚簇索引（主键索引）上触发，只作用于二级索引（包括联合索引）。它的核心是“利用索引里已有的字段做前置过滤”。
- 比如有联合索引
idx_name_age(name, age)，执行SELECT * FROM t WHERE name LIKE '张%' AND age = 10，name LIKE '张%'用于索引范围扫描，age = 10就能被下推到引擎层，在B+树叶子节点遍历时直接比对 —— 不满足的条目连主键都不取，自然不用回表 - 但如果写成
name LIKE '%张'（左模糊），name无法走索引范围查找，整个索引失效，ICP也就无从谈起 - 非索引列条件（如
address = '杭州'）永远不能下推，只能留在Server层过滤
如何确认ICP是否实际启用：看EXPLAIN的Extra字段
执行 EXPLAIN SELECT ... 后，重点检查 Extra 列：
- 出现
Using index condition→ ICP已生效 - 只有
Using where→ 条件全在Server层过滤，未下推 - 出现
Using index→ 覆盖索引，根本不需要回表，ICP不参与
注意：Using index condition 和 Using where 可能同时出现，说明部分条件下推、部分没下推。
ICP在5.7+默认开启，但某些场景会自动禁用
虽然 optimizer_switch 中 index_condition_pushdown=on 是默认值，但以下情况ICP会被绕过：
- 查询使用了
SELECT *且二级索引不覆盖所有WHERE中涉及的列，但引擎发现下推逻辑复杂（如含子查询、UDF、全文检索函数），会退回到Server层过滤 - 事务隔离级别为
SERIALIZABLE时，部分版本（如5.7.20前）会禁用ICP以保证一致性 - 使用了
FORCE INDEX但该索引结构不支持下推（例如前导列是函数索引或虚拟列，且优化器未识别其可下推性）
可通过 SHOW VARIABLES LIKE 'optimizer_switch'; 确认当前开关状态，但更可靠的方式是始终以 EXPLAIN 输出为准。
容易被忽略的关键点：ICP不改变索引扫描范围，只减少回表行数
很多人误以为ICP能“让查询更快地定位到目标行”，其实不是。它不加速索引查找本身，而是减少无效回表——也就是说：
- 扫描的索引页数量不变（仍按
name LIKE '张%'找出所有匹配的叶子节点） - 但在每个匹配的索引项上，InnoDB会立刻拿
age值做比较；失败的项直接跳过，不生成回表请求 - 最终IO下降、Buffer Pool压力降低、CPU在Server层做的行过滤也变少
所以，在千万级数据、高并发OLTP场景下，哪怕只是把平均每次查询的回表从5次降到1次，整体吞吐提升也极为明显——但这依赖你真正建对了联合索引，并让关键过滤字段落在索引定义的后缀位置。
