ICP（索引条件下推）是MySQL优化器在满足四个硬性条件时启用的优化机制：WHERE中存在可下推的非主键索引谓词、访问类型为range/ref/eq_ref/index_merge、存储引擎支持（如InnoDB）、optimizer_switch中index_condition_pushdown=on。
ICP 是什么，什么时候真正起作用
ICP 不是默认全开的优化，它只在满足特定条件时才被 MySQL 优化器启用。核心判断依据是：索引是否能“覆盖” WHERE 条件中的部分谓词，且这些谓词无法由存储引擎用索引直接完成完整匹配（即不能全下推到引擎层做“索引扫描过滤”），但又适合在引擎读取索引记录后、回表前就提前过滤。
必须同时满足的 4 个硬性条件
缺一不可，任意一条不满足，ICP 就不会触发：
-
WHERE中存在可下推的非主键索引字段谓词，例如col1 = ? AND col2 > ?，其中(col1, col2)是联合索引，col1 = ?用于定位索引范围，col2 > ?可下推 - 查询使用的是
range、ref、eq_ref或index_merge访问类型（ALL或index全扫描不启用 ICP） - 存储引擎支持 ICP —— MySQL 8.0+ 的
InnoDB和MyISAM支持，但Memory引擎不支持 -
optimizer_switch中的index_condition_pushdown必须为on（默认是开启的，但可通过SET optimizer_switch='index_condition_pushdown=off'关闭）
容易被忽略的失效场景
即使语法和索引结构看起来合理，ICP 也可能静默失效：
- 谓词含函数或表达式：如
YEAR(create_time) = 2023或col + 1 > 100—— 无法下推 - 涉及隐式类型转换：比如索引列是
VARCHAR，但条件传入整数WHERE str_col = 123，MySQL 可能放弃 ICP 以保证语义正确 - 使用了
SELECT *且索引不覆盖所有需要字段，但 ICP 本身不依赖是否覆盖，真正影响的是“是否值得下推”——如果回表成本低，优化器可能主动跳过 ICP -
EXPLAIN中Extra列没出现Using index condition，就说明 ICP 没生效；注意它和Using where不同，后者是 Server 层过滤，前者才是 ICP
如何验证 ICP 是否实际工作
别只看执行计划，要结合 STATUS 和真实行为确认：
- 执行
EXPLAIN FORMAT=TRADITIONAL或EXPLAIN FORMAT=JSON，检查Extra字段是否含Using index condition - 对比开启/关闭 ICP 后的
Handler_read_next和Handler_read_rnd_next值：ICP 生效时，前者通常显著减少（引擎层过滤掉更多索引项），后者可能变化不大或略降（回表次数未同比例下降） - 用
SELECT ... INTO DUMPFILE或慢日志中的rows_examined辅助判断：ICP 减少的是引擎层遍历的索引记录数，不是最终返回行数
最麻烦的地方在于：ICP 的启用与否由优化器基于成本估算决定，同样的 SQL 在不同数据分布、统计信息、缓冲区大小下可能表现不一致 —— 它不是开关式功能，而是权衡后的动态选择。
