索引条件下推（ICP）是 MySQL 5.6+ 优化技术，允许将 WHERE 中可由索引字段判断的条件下推至存储引擎层，在索引扫描时提前过滤，减少回表和 I /O。
在 SQL 查询中，索引条件下推（Index Condition Pushdown, ICP）是 MySQL 5.6+ 引入的一项优化技术，核心目标是让存储引擎层在索引扫描过程中提前过滤数据，从而减少回表或读取完整行的次数，显著降低 I / O 开销。
什么是索引条件下推
ICP 允许 MySQL 将 WHERE 子句中能被索引字段直接判断的条件，下推到存储引擎层执行。传统方式下，存储引擎只按索引查找匹配的主键或 ROWID，再由 Server 层对取出的整行数据做条件过滤；而启用 ICP 后，引擎在遍历索引 B + 树节点时，就用索引列上的条件做过滤，跳过明显不满足的索引项，避免不必要的回表或聚簇索引访问。
什么情况下会触发 ICP
ICP 生效需同时满足以下条件：
- 使用的是 二级索引（非聚簇索引），因为聚簇索引本身就包含完整行数据，无需额外回表
- 查询条件中包含该二级索引的 前导列或覆盖列，且部分条件无法被索引最左前缀完全利用（例如联合索引 (a,b,c)，WHERE a=1 AND b>5 AND d=10，其中 d 不在索引中，但 a、b 可走索引，ICP 可对 b > 5 在引擎层判断）
- 存储引擎支持 ICP（InnoDB 和 MyISAM 均支持，但 MyISAM 仅限于某些版本）
- 优化器认为 ICP 收益大于开销（如条件过滤率高、回表代价大时更倾向启用）
如何确认 ICP 是否生效
通过 EXPLAIN FORMAT=JSON 或EXPLAIN ANALYZE（MySQL 8.0.18+）查看执行计划：
- 在 “using_index_condition”: true 字段出现，表示 ICP 已启用
- 对比启用前后 Handler_read_next 或Handler_read_rnd_next等状态变量的变化：ICP 生效后，后者通常明显减少
- 使用 SHOW STATUS LIKE ‘Handler%’ 观察实际行读取量变化
如何提升 ICP 效果
并非所有索引设计都利于 ICP 发挥价值，关键在于让条件尽可能“落在索引上”：
- 为常用过滤字段建立 复合索引，把高选择性、常用于范围 / 等值判断的列前置（如 WHERE status=1 AND create_time > ‘2024-01-01’ AND type IN (…)，建议索引为 (status, create_time, type)）
- 避免在索引列上使用函数或表达式（如 WHERE YEAR(create_time)=2024），这会导致索引失效，ICP 也无法介入
- 尽量使 WHERE 条件覆盖索引前缀，尤其是范围条件之后的等值条件（ICP 对范围后的等值列仍可下推判断）
- 对频繁查询的宽表，考虑添加 覆盖索引，彻底避免回表，此时 ICP 虽不涉及回表，但仍可加速索引扫描本身
