索引下推（icp）是将server层的部分where条件判断提前至存储引擎层在索引扫描时执行，减少无效回表；需满足使用range/ref等访问类型、过滤列全部包含在同一二级索引中、且引擎为innodb或myisam三个前提，explain中出现“using index condition”即表示生效。
索引下推（Index Condition Pushdown，ICP）的本质，是把原本由 MySQL Server 层负责的部分 WHERE 条件判断，提前交给存储引擎层在索引扫描阶段完成。它不改变索引结构，也不新增索引，而是优化了查询执行路径——让过滤动作更靠近数据源头。
为什么需要下推：Server 层和引擎层的分工差异
MySQL 查询分两层协作：Server 层负责解析、优化、聚合等逻辑；InnoDB 等存储引擎负责实际读取数据。传统方式中，只要索引能定位到候选记录（比如用 name='张%' 找到几条主键），引擎就会把这些主键全部回表取整行，再把完整行交给 Server 层去判断 age=10 是否成立。这意味着大量无效回表——尤其是当联合索引里已包含 age 字段时，却白白多走一次聚簇索引访问。
ICP 把这个“判断 age=10”的动作，直接挪到引擎读取索引项的时候做：引擎一边遍历 (name, age) 联合索引，一边检查索引节点里的 age 值是否满足条件。不满足的索引项直接跳过，根本不用回表。
ICP 的执行机制依赖三个关键前提
- 必须使用支持 ICP 的访问类型：仅限 range、ref、eq_ref、ref_or_null 这几类索引访问方式。全表扫描（ALL）、索引扫描（index）或无法利用索引做范围查找的查询，不会触发 ICP。
- 过滤条件必须能被索引覆盖：WHERE 中用于下推的列，必须全部出现在同一个二级索引中。例如联合索引 (name, age)，可下推 name = '李' AND age > 15；但若加了 address = '杭州'（address 不在该索引中），这部分仍需 Server 层过滤。
- 仅对二级索引生效，且要求引擎为 InnoDB 或 MyISAM：聚簇索引（主键索引）本身存的是完整行，不存在“回表”问题，因此无需也无从下推；ICP 是为减少二级索引回表而生的优化。
如何确认是否启用了索引下推
执行 EXPLAIN 查看执行计划，在 Extra 列中出现 Using index condition 即表示 ICP 已生效。例如：
EXPLAIN SELECT * FROM tuser WHERE name LIKE '张%' AND age = 10;
若 Extra 显示 Using index condition，说明 InnoDB 在 (name, age) 索引上先按 name 匹配，再当场用索引里的 age 值筛掉不等于 10 的项，只对真正符合条件的索引条目执行回表。
ICP 带来的实际收益
- 减少回表次数：从“先取所有匹配 name 的行再筛 age”，变成“只取 name 和 age 都匹配的行再回表”。在高基数联合索引中，回表量可能下降数倍。
- 降低 IO 开销：避免大量随机读聚簇索引页（回表本质是按主键值随机访问），尤其在 SSD 或高并发场景下效果明显。
- 减少网络与内存传输量：Server 层接收的数据量变小，减轻执行器压力，也利于后续排序、分组等操作。
