icp能减少回表次数，因其将部分where条件下推至存储引擎层，在遍历二级索引时提前过滤不满足条件的索引项，避免无效回表；仅字段在当前二级索引中且操作符被支持的条件才可下推。
ICP 为什么能减少回表次数
回表的本质是：二级索引只存字段值+主键ID，要查其他字段就得拿着ID去聚簇索引里再查一次完整行。每一次回表都意味着至少一次随机磁盘 I/O（尤其在机械盘或高并发下代价极高）。ICP 把部分 WHERE 条件“塞进”存储引擎层，在遍历二级索引时就做判断，不满足的索引项直接跳过，根本不触发回表。
关键点在于：不是所有条件都能下推，只有那些「字段在当前使用的索引中存在」且「能被存储引擎解析」的条件才可能下推。比如联合索引 idx_name_age(name, age)，name = '张三' AND age > 20 中的 age > 20 就能下推；但 address LIKE '%杭州%' 就不能——因为 address 不在该索引里。
如何确认 ICP 是否真正生效
看 EXPLAIN 输出的 Extra 列是否含 Using index condition。这是唯一可靠信号，不是“用了索引”或“走了联合索引”就代表 ICP 生效。
- 如果出现
Using where但没有Using index condition，说明过滤全在 Server 层，ICP 没起作用 - 如果同时出现
Using index（覆盖索引）和Using index condition，说明既没回表、又用了 ICP——但此时 ICP 实际无意义，因为根本不需要回表 - 注意
key列必须是非主键索引（即二级索引），主键索引上不会触发 ICP
哪些条件能下推？哪些不能？
能下推的条件必须满足两个硬性前提：字段属于当前扫描的二级索引，且操作符被引擎支持。常见可下推操作包括：
-
=、>、、<code>>=、、<code>BETWEEN -
LIKE前缀匹配（如name LIKE '张%'），但不能是通配符开头（name LIKE '%张'） - 多个条件组合时，只要每个子条件字段都在索引中，且逻辑关系是
AND，通常都能下推
不能下推的典型情况：
- 涉及非索引字段的条件（如
email = 'a@b.com'，但索引是(name, age)） -
OR连接的条件（即使字段都在索引中，优化器一般也不会下推） - 函数包裹字段（如
UPPER(name) = 'ZHANG'，索引失效，更谈不上下推） - 隐式类型转换（如索引字段是
VARCHAR，但查询用数字name = 123）
ICP 生效还依赖什么配置和版本
MySQL 5.6+ 默认开启，但需确认：optimizer_switch 变量中 index_condition_pushdown 是 on。可通过以下命令检查：
SHOW VARIABLES LIKE 'optimizer_switch';
输出中应包含 index_condition_pushdown=on。若为 off，可用：
SET SESSION optimizer_switch="index_condition_pushdown=on";
注意：ICP 仅对 InnoDB 和 MyISAM 存储引擎有效，Memory 引擎不支持；且只在使用二级索引扫描时触发，全表扫描或主键扫描都不走 ICP。
最易被忽略的一点：即使满足所有条件，优化器也可能因统计信息偏差、小数据量或成本估算认为不值得下推而放弃 ICP——所以永远以 EXPLAIN 的 Using index condition 为准，而不是“理论上应该生效”。
