using index condition明确表示mysql将部分where条件下推至innodb引擎层过滤，需同时满足：走二级索引、条件字段在索引中且可直接计算、mysql≥5.6且icp开关开启、优化器判定下推划算。
“Using index condition”不是索引被用了的模糊提示，而是明确告诉你：MySQL把部分WHERE条件真的下推到了InnoDB存储引擎层，在扫描二级索引时就做了过滤。
为什么EXPLAIN里出现Using index condition就说明ICP生效了
这个标记只在满足四个硬性条件时才出现，缺一不可：
- 查询走的是二级索引（比如
KEY idx_city_age (city, age)），聚簇索引（主键）上永远不会出现 -
WHERE中至少有一个条件能用该索引字段直接计算，比如city = '杭州'或age > 25，且字段必须在索引定义中 - MySQL版本 ≥ 5.6，且
optimizer_switch中index_condition_pushdown为on（默认开启，但可被手动关掉） - 优化器评估后认为下推划算——比如复杂子查询、外连接中它可能自动禁用
注意：key_len值不会因为ICP而变长，它只反映最左前缀匹配长度；Using index condition和Using where是互斥信号：前者表示部分条件已在引擎层过滤，后者意味着所有过滤都压在Server层。
哪些WHERE条件能被真正下推到引擎层
ICP不接受任意条件，只认“引擎能拿索引值原样比对”的表达式。关键看两点：字段是否在当前索引中、写法是否支持B+树快速跳查或逐项检查。
- ✅ 可下推：
status = 1、name LIKE 'Li%'、age IN (20, 25, 30)、create_time > '2024-01-01' - ❌ 不可下推：
UPPER(name) = 'LI'、YEAR(create_time) = 2025、name LIKE '%li'、id + 1 = 100 - ⚠️ 隐式转换会直接让ICP失效：比如索引列是
VARCHAR，却写成WHERE city = 123（数字类型），引擎无法安全下推
联合索引顺序也影响下推能力。例如索引(a, b, c)，WHERE a = 1 AND c = 3中只有a = 1用于定位，c = 3无法下推（b缺失导致连续性中断）；而WHERE a = 1 AND b > 10 AND c = 5三者都可能下推。
Using index condition出现≠查询一定变快
它只代表“下推动作发生了”，不代表性能提升。真实收益取决于过滤效果和当前瓶颈：
- 如果前导列选择性差（比如
gender = 'M'匹配近半数据），引擎要遍历大量索引项并逐条解码比较，CPU开销反而略增 - 若数据全在Buffer Pool里，回表开销极小，ICP减少的IO几乎不可测
- SELECT * 导致频繁回表，但ICP只筛掉5%的索引项，随机IO仍是瓶颈，提速不明显
验证是否真起作用，不能只看EXPLAIN：执行SET optimizer_switch='index_condition_pushdown=off';后再对比SHOW STATUS LIKE 'Handler_read_rnd_next'——关闭ICP后这个值应明显上升，才是实锤。
最容易被忽略的一点是：ICP依赖“回表”这个动作存在。如果查询本身是覆盖索引（Extra显示Using index），根本不需要回表，ICP就无用武之地——哪怕WHERE条件完全符合下推规则，也不会出现Using index condition。
