MySQL索引下推将WHERE中能用索引字段直接判断的条件（如=、>、LIKE前缀匹配等）下推至存储引擎层过滤，仅限索引包含的列且需满足最左前缀匹配；未命中索引或含函数/模糊后缀的条件仍由Server层处理，EXPLAIN中显示“Using index condition”即生效。
MySQL索引下推执行时，条件怎么被“下推”到引擎层？
索引下推不是把整个 WHERE 条件都扔给存储引擎，而是只把「能用索引字段直接判断」的部分下推。比如联合索引 (city, age)，查询 WHERE city = '杭州' AND age > 20 AND name LIKE '%老王%'，只有 city = '杭州' 和 age > 20 可以下推——因为它们对应索引里的列；name LIKE 不在索引中，必须留在 Server 层过滤。
关键点在于：下推的条件必须满足两个前提：
- 字段必须出现在当前使用的索引中（顺序无关，但需存在）
- 该条件必须能被存储引擎原生支持（如
=、IN、BETWEEN、>、<、LIKE前缀匹配等；但LIKE '%xxx'或函数表达式如UPPER(name) = 'ABC'就不行）
如何确认某条 SQL 是否真的触发了索引下推？
看 EXPLAIN 输出的 Extra 列。如果显示 Using index condition，说明用了 ICP；如果只显示 Using where，说明条件全在 Server 层过滤；如果是 Using index，那属于覆盖索引，根本没回表，和 ICP 无关。
注意几个常见误判场景：
- 索引不是联合索引（比如单列索引），ICP 没意义——单列索引下推不了“额外”字段
- 查询用了
SELECT *但索引不覆盖所有字段，仍会回表，但 ICP 可能仍在生效（只要部分条件能下推） -
optimizer_switch中index_condition_pushdown被设为off，即使满足条件也不会启用（可通过SHOW VARIABLES LIKE '%optimizer_switch%'查看）
为什么有时候明明建了联合索引，ICP 却没生效？
最常见原因是「最左前缀未匹配」或「条件类型不支持」。例如索引是 (a, b, c)，但查询写成 WHERE b = 1 AND c > 10，由于跳过了 a，索引无法从头开始定位，整个索引扫描都失效，ICP 自然无从谈起。
其他典型失效情况包括：
- 对索引字段做了计算或函数操作，如
WHERE YEAR(create_time) = 2024 - 使用了不支持下推的运算符，比如
IS NULL在某些版本中不参与 ICP（取决于引擎实现） - 使用了
OR连接多个条件，且部分分支无法走索引，优化器可能放弃 ICP 路径 - 查询涉及隐式类型转换，导致索引列实际未按原始类型参与比较
ICP 对性能的真实影响有多大？
它不改变索引扫描范围，但显著减少回表次数和 Server 层处理的数据量。假设联合索引 (zipcode, lastname) 上有 10 万行 zipcode = '95054'，其中只有 120 行满足 lastname LIKE 'Z%'，ICP 能让引擎直接在索引页里筛掉 99880 条，只回表 120 次；没有 ICP 就得先回表 10 万次，再在 Server 层逐条过滤。
这种差异在磁盘 I/O 密集型查询中尤为明显——尤其是当 extra 字段很大、或表行数极多时。但要注意：ICP 本身有轻微 CPU 开销（引擎层多做一次判断），所以对已经极小结果集的查询（比如 WHERE id = ?），几乎看不出差别。
真正容易被忽略的是：ICP 的收益高度依赖数据分布和条件选择性。如果 age > 20 在 city = '杭州' 下几乎总是成立，下推带来的剪枝效果就微乎其微——这时候优化重点该转向更精准的索引设计或统计信息更新。
