using index condition仅表示mysql“尝试启用”索引下推（icp），不保证实际生效；需用explain analyze验证真实过滤阶段，且icp仅在必须回表时触发，覆盖索引或聚簇索引查询中不适用。
EXPLAIN 的 Using index condition 不代表一定生效
很多人看到 EXPLAIN 输出中 Extra 列有 Using index condition 就认为 ICP 已起作用，但这是误导。这个字段在 MySQL 5.6+ 中只要优化器“打算”用 ICP 就会写入，哪怕最终因条件不满足而被引擎层跳过。它只表示“尝试启用”，不反映实际执行路径。
用 EXPLAIN ANALYZE 看真实过滤阶段
MySQL 8.0+ 必须用 EXPLAIN ANALYZE（不是普通 EXPLAIN）来验证 ICP 是否真正触发：
- 执行
EXPLAIN ANALYZE SELECT ... WHERE ... - 查找输出中是否出现类似
-> Filtered: 85.00 (index condition)的行 - 或明确看到子节点标注
index condition pushdown或ICP - 若只有
-> Filtered: 85.00且无括号说明，说明过滤发生在 Server 层，ICP 未生效
哪些 WHERE 条件会导致 ICP 失效
即使索引结构合适、MySQL 版本支持，以下情况也会让 ICP 被绕过：
-
LIKE模式以%开头（如lastname LIKE '%etrunia%'），InnoDB 无法在索引内做前缀跳过 - 条件中包含函数调用（如
UPPER(col) = 'ABC'、YEAR(created_at) = 2023） - 涉及子查询（如
col1 IN (SELECT x FROM t2)） - 使用虚拟生成列（virtual generated column）上的索引
- 查询使用了覆盖索引（
Using index），无需回表，ICP 自然无意义
确认全局开关和表级行为
ICP 默认开启，但可能被显式关闭或受隔离级别/事务状态影响：
- 查当前设置：
SHOW VARIABLES LIKE 'optimizer_switch';，确认其中包含index_condition_pushdown=on - 临时关闭测试：
SET SESSION optimizer_switch = "index_condition_pushdown=off"; - 注意：MyISAM 不支持 ICP；只有 InnoDB 和部分 NDB 表可用
- 联合索引中，范围查询后的列（如
INDEX(a,b,c)中WHERE a > 1 AND b = 2）——b可下推；但WHERE a = 1 AND c = 3中c不可下推（跳过b）
最易被忽略的是：ICP 生效的前提是“必须回表”。如果查询能走覆盖索引，或者用了主键聚簇索引直接读全行，ICP 就不会参与——它专为减少二级索引回表而生，不是万能过滤器。
