Using index condition 表示 MySQL 启用了索引条件下推（ICP）优化，将部分 WHERE 条件下推至存储引擎层（如 InnoDB）在二级索引遍历中提前过滤，减少回表次数，仅对二级索引生效且要求条件可由索引字段独立评估。
Using index condition 出现在 EXPLAIN 的 Extra 字段里，说明 MySQL 正在用索引下推（ICP）优化查询
这个值不是“用了索引”或“覆盖索引”的简单标志，而是明确告诉你：MySQL 把部分 WHERE 条件下推到了存储引擎层，在遍历二级索引时就做了初步过滤，而不是等回表后才在 server 层判断。
它只出现在使用二级索引（非主键索引）且满足特定条件的场景中，主键索引（聚簇索引）永远不会触发 ICP —— 因为叶子节点已经是整行数据，下推没意义。
常见触发条件包括：
-
LIKE 'prefix%'配合联合索引的前导列（如name），同时后续列也在WHERE中参与过滤（如age = 25） - 联合索引中前导列是等值匹配（
=），后续列是范围/模糊/等值条件（如(name, age, position)索引，查询WHERE name = 'LiLei' AND age > 20 AND position LIKE 'Eng%'） - MySQL 版本 ≥ 5.6，且
optimizer_switch中的index_condition_pushdown是on（默认开启）
为什么看到 Using index condition 反而可能比 Using where;Using index 慢？
表面看 ICP 减少了回表次数，但实际性能要看“下推过滤的有效性”。如果索引中能提前筛掉大量无效行，ICP 就很划算；但如果过滤效果差，反而多了一次引擎层判断开销。
典型低效场景：
- 联合索引前导列选择性极低（比如
gender只有 'M'/'F'），导致扫描大量索引项，每项都得做一次age或position判断 - 条件中含函数或表达式（如
WHERE YEAR(hire_time) = 2025），无法下推，ICP 不生效，但执行计划仍显示Using index condition（此时只是“尝试下推失败”，别被误导） - 查询字段太多，即使用了 ICP，最终仍需频繁回表，而随机 IO 成为瓶颈（尤其 SSD 性能差异小、HDD 上更明显）
如何确认 ICP 是否真正在工作？
不能只看 EXTRA 字段，要对比开启/关闭 ICP 后的 rows 和实际执行耗时：
- 临时关闭：
SET optimizer_switch='index_condition_pushdown=off';，再EXPLAIN和BENCHMARK对比 - 观察
rows值变化：启用 ICP 后，rows应显著减少（代表引擎层已筛掉一部分）；若几乎不变，说明下推条件未被真正利用 - 检查
key_len：是否只用到了联合索引的前缀部分？比如索引是(a,b,c)，key_len显示只用了a的长度，那b/c的条件大概率没参与索引查找，只能靠 ICP 过滤
注意：Using index condition 和 Using where;Using index 可能共存于同一执行计划——前者指引擎层过滤，后者指 server 层仍需对回表后的完整行做剩余条件判断。
容易被忽略的关键限制
ICP 不是万能的，几个硬性约束常被忽略：
- 只适用于 InnoDB 的二级索引；MyISAM 不支持，InnoDB 主键索引也不支持
- 不支持全文索引、空间索引、哈希索引（Memory 引擎）
- 当
WHERE中存在需要访问整行数据才能计算的条件（如JSON_CONTAINS()、子查询、OR连接多个索引列条件），ICP 会自动退化 - 如果查询用了
SELECT *且二级索引无法覆盖所有字段，回表不可避免，ICP 的收益上限就是“少回几条”，而非“免回表”
最隐蔽的问题是：开发时在测试库看到 Using index condition，上线后因数据分布变化（比如 name 前缀重复暴增），ICP 过滤效率骤降，慢查询突然复现——这时候光看执行计划不够，得结合 SHOW PROFILE 或 performance_schema 查 IO 和 CPU 耗时分布。
