Using index condition 表示 MySQL 启用了 ICP 优化，将部分 WHERE 条件下推至存储引擎层（如 InnoDB）在二级索引遍历中提前过滤，减少回表或 Server 层判断开销；但仅当下推条件选择性高且能由索引字段独立评估时才真正提升性能。
Using index condition 出现在 EXPLAIN 的 Extra 列里，说明 MySQL 正在用 ICP（Index Condition Pushdown）优化——它把部分 WHERE 条件下推到 InnoDB 存储引擎层，在读取二级索引项时就做初步过滤，而不是先回表再判断。
为什么看到 Using index condition 却没变快？
ICP 不减少索引扫描行数，只减少回表或 Server 层处理的数据量。如果下推的条件选择性很差（比如 status = 0 匹配 95% 的行），引擎每条索引记录都得解码、比较，反而可能略增 CPU 开销。
- 真实收益要看
SHOW STATUS LIKE 'Handler%'：关注Handler_read_next（索引遍历次数）是否下降，以及Handler_icp_attempts是否接近它 -
key_len很小但出现Using index condition，往往意味着只有前导列走索引，后续等值条件被下推了——索引利用效率其实不高 - 含子查询、
UNION或外连接的语句，ICP 可能被优化器自动禁用，即使optimizer_switch里开着
哪些条件能被 ICP 下推？
必须是“能仅靠索引字段独立计算”的表达式，InnoDB 才能在不读聚簇索引的前提下完成判断。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 支持：
c = 10、c IN (1,2,3)、c BETWEEN 5 AND 8 - 不支持：
UPPER(c) = 'ABC'（函数调用）、c + 1 > 5（表达式计算）、c LIKE '%abc'（左模糊，无法用索引值直接比对） - 虚拟生成列上的二级索引不支持 ICP
- 引用子查询、存储函数或触发器的条件一律不能下推
怎么确认某个条件真被下推了？
最可靠的方法是关掉 ICP 对比执行计划和实际开销：
SET optimizer_switch='index_condition_pushdown=off'; EXPLAIN SELECT * FROM t WHERE a = 1 AND b > 5 AND c = 10;
你会看到 Extra 变成 Using where，且 rows 预估值通常变大——因为 Server 层要接收更多中间结果。
- 注意：ICP 默认开启（MySQL 5.6+ 的
optimizer_switch中index_condition_pushdown=on） - MyISAM 支持 ICP，Memory 引擎不支持
- ICP 只对二级索引生效；主键/聚簇索引本身就要读整行，下推无意义
ICP 的价值不在“有没有”，而在“推得准不准”——它依赖索引结构、条件写法、数据分布三者配合。哪怕执行计划里出现了 Using index condition，也要结合 Handler 状态变量和实际 QPS/延迟验证效果，否则容易误判优化成功。
