using index condition 表示mysql启用icp优化，将部分where条件下推至innodb存储引擎层，在二级索引遍历时提前过滤，减少回表；仅适用于二级索引，要求条件可由索引字段独立评估。
Using index condition 说明 MySQL 正在用 ICP 优化
这个提示不是“索引被用了”的模糊信号，而是明确告诉你：MySQL 把部分 WHERE 条件下推到了 InnoDB 存储引擎层，在遍历二级索引（非主键索引）时就做了过滤，而不是等回表后再判断。
它只出现在二级索引扫描中；主键/聚簇索引上永远不会出现——因为叶子节点就是整行数据，下推没意义。
- 典型组合是：
type为ref或range，key显示用了某个联合索引，Extra同时有Using index condition - 这意味着前导列定位了索引范围，后续列的条件被下推执行了（比如索引
(a, b, c)，查询WHERE a = 1 AND b > 10 AND c = 5） -
key_len仍只反映最左匹配长度，不因下推而变长——它不改变索引是否“被使用”的判断逻辑
哪些 WHERE 条件能被真正下推？
ICP 要求条件必须能“纯靠索引字段算出来”，不能依赖聚簇索引行数据，也不能触发隐式转换或函数调用。
- ✅ 可下推：
c = 10、c IN (1,2,3)、c > 5、c BETWEEN 1 AND 100、c LIKE 'abc%' - ❌ 不可下推：
UPPER(c) = 'ABC'、c + 1 > 10、c IN (SELECT x FROM t2)、address LIKE '%北京%'（非索引列）、NOW() > create_time - ⚠️ 隐式转换直接让 ICP 失效：比如索引列是
VARCHAR，但写成WHERE c = 123（数字比较），引擎无法安全下推
为什么看到 Using index condition 却没变快？
ICP 不减少索引扫描行数，只减少回表或 Server 层处理的数据量。低选择性条件反而可能增加 CPU 开销。
- 如果下推条件匹配 90% 的索引项（比如
status = 0），每条索引记录都要解码+比较，徒增引擎层负担 -
key_len很小但出现Using index condition，往往意味着只有前导列走索引，后续等值条件被下推了——索引利用效率其实不高 - 含子查询、
UNION或外连接的语句，ICP 可能被优化器自动禁用，即使optimizer_switch里开着
怎么确认某个条件真被下推了？
不能只看 EXPLAIN 输出，得关掉 ICP 对比真实行为。
- 临时关闭：
SET optimizer_switch='index_condition_pushdown=off';，再跑EXPLAIN - 你会看到
Extra变成Using where，且rows预估值通常变大——因为 Server 层要接收更多中间结果 - 查状态变量：
SHOW STATUS LIKE 'Handler%';，重点关注Handler_read_next（索引遍历次数）是否下降，以及Handler_icp_attempts是否接近它
ICP 默认开启（MySQL 5.6+），但它真正的价值不在“有没有”，而在“推得准不准”——依赖索引结构、条件写法、数据分布三者配合。哪怕执行计划里出现了 Using index condition，也要结合 Handler 状态和实际 QPS/延迟验证效果，否则容易误判优化成功。
