using index condition 表示icp生效，即mysql将部分where条件下推至innodb存储引擎层，在二级索引扫描时提前过滤，减少回表；它要求使用二级索引、条件可由索引字段独立计算、mysql≥5.6且optimizer_switch开启，但不保证性能提升。
Using index condition 出现在 EXPLAIN 里，说明 ICP 生效了
它不是“用了索引”的模糊提示，而是明确告诉你：MySQL 把部分 WHERE 条件下推到了 InnoDB 存储引擎层，在扫描二级索引时就做了过滤，而不是等回表取整行后再判断。
这个标记只在满足特定组合时才出现，缺一不可：
- 查询使用的是二级索引（非主键索引），聚簇索引永远不会触发 ICP
-
WHERE中有能由该索引字段独立计算的条件（比如name LIKE 'Li%'、age = 25），且这些字段都在索引定义中 - MySQL 版本 ≥ 5.6，且
optimizer_switch中的index_condition_pushdown是on（默认开启） - 优化器评估后认为下推比 Server 层过滤更划算（某些复杂子查询或外连接中可能被自动禁用）
哪些 WHERE 条件能被真正下推？
ICP 不是把所有条件都扔给引擎，它只接受「引擎能直接拿索引值算出来」的表达式。关键看字段是否在当前索引中、写法是否支持 B+ 树快速跳查或逐项检查。
- ✅ 可下推：
zipcode = '100001'、name LIKE '陈%'、status IN (0, 1)—— 字段在索引里，且不涉及计算或函数 - ❌ 不可下推：
UPPER(name) = 'LI'、YEAR(hire_time) = 2025、name LIKE '%陈'—— 引擎无法用原始索引值直接比对 - ⚠️ 容易误判：
name LIKE '%陈%'虽不能做范围跳查，但若name在索引中，ICP 仍可能在引擎层逐条检查索引项里的name值，此时Using index condition会显示，但实际过滤效率极低
看到 Using index condition 就一定更快？
不一定。这个标记只代表“下推动作发生了”，不代表性能提升。真实收益取决于过滤效果和瓶颈位置。
- 如果前导列选择性差（比如
gender = 'M'匹配 48% 行），引擎仍要遍历大量索引项，每项都做一次字段解码和比较，CPU 开销反而略增 - 如果查询本身只返回 1 行，且数据全在 Buffer Pool 里，回表开销微乎其微，ICP 带来的减少几乎不可测
- 如果
SELECT *导致频繁回表，而 ICP 只筛掉 5% 的索引项，那么随机 IO 仍是瓶颈，提速不明显 - 验证是否真起作用：执行
SET optimizer_switch='index_condition_pushdown=off';后再EXPLAIN和BENCHMARK对比；更准的方法是查SHOW STATUS LIKE 'Handler_read_rnd_next'—— 关闭 ICP 后这个值应明显上升
key_len 小但 Extra 有 Using index condition，说明什么？
这很常见，也最容易被忽略。它意味着：索引只用到了最左前缀部分（比如联合索引 (a, b, c)，key_len 显示只用了 a 的长度），但 b = ? 或 c LIKE 'x%' 这类条件被下推了，引擎在扫描所有匹配 a 的索引项时，顺手在叶子节点里检查了 b 或 c 的值。
这种情况下，索引利用效率其实不高——不是“高效定位”，而是“先扫一大片，再靠 ICP 挨个筛”。如果你发现 rows 预估没变小，或者 Handler_read_next 很高，那大概率就是这种情况。
