ICP能减少交互次数，因它将部分WHERE条件下推至InnoDB层，在索引扫描时预过滤，仅满足条件的索引项才触发回表；EXPLAIN中出现Using index condition即表示启用ICP优化。
ICP 为什么能减少执行器与存储引擎的交互次数
因为 ICP 把部分 WHERE 条件的判断逻辑从 Server 层（执行器）下推到了存储引擎层，让引擎在读取索引元组时就做初步过滤，而不是把所有匹配索引的行都回表取完整记录再交给 Server 层筛。
Using index condition 出现在 EXPLAIN 的 Extra 列意味着什么
它明确表示 MySQL 正在使用 ICP 优化。此时存储引擎不是简单地按索引查出主键再回表，而是在索引扫描阶段就用上非最左前缀、范围或模糊匹配等“无法直接走索引查找”的条件做预筛。
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 对比
Using where：后者代表所有索引匹配的行都已回表取了整行，才由 Server 层逐行判断WHERE剩余条件 - ICP 下，只有满足下推条件的索引条目才会触发回表，大幅减少无效回表次数
- 特别在复合索引中，比如
INDEX(a, b)，查询WHERE a = 1 AND b LIKE '%x%'，b的模糊匹配无法用于索引查找，但可被 ICP 下推
ICP 不生效的常见原因
即使 MySQL 8.0 默认开启 ICP（optimizer_switch='index_condition_pushdown=on'），它也受访问类型和索引结构限制：
- 只对
range、ref、eq_ref、ref_or_null类型生效；ALL（全表扫描）或index（全索引扫描）不触发 ICP - 下推条件必须能被存储引擎解析——例如
JSON_CONTAINS()或用户自定义函数通常无法下推 - 如果查询用了
SELECT *且索引不覆盖所有列，引擎仍需回表，但 ICP 可先筛掉一批明显不满足条件的索引项，降低回表基数 - 某些存储引擎（如 MyISAM）不支持 ICP，InnoDB 从 5.6 起支持，8.0 完全继承并默认启用
ICP 和覆盖索引的关系容易被混淆
二者目标一致（减少回表/IO），但机制完全不同：
- 覆盖索引靠「索引里存齐了要查的所有字段」，根本不用回表
- ICP 靠「在回表前多筛一轮」，不能避免回表，但让回表更精准
- 一个查询可能同时受益于两者：比如
INDEX(a, b, c)上执行SELECT a, b FROM t WHERE a = 1 AND c > 100，既满足覆盖（a,b都在索引中），又触发 ICP（c > 100条件下推） - 真正容易被忽略的是：ICP 的收益高度依赖数据分布——如果下推条件过滤率很低，它节省的回表次数有限，甚至可能因额外判断带来微小开销
