explain中未出现using index condition表明索引下推（icp）未生效，根本原因是mysql未将非前缀条件下推至索引层过滤，常见于版本低于5.6、使用主键索引、联合索引前缀缺失、like前导通配符、or条件破坏索引连续性等情况。
为什么EXPLAIN里看不到Using index condition
索引下推（ICP）未生效，最直接的信号就是执行计划中 Extra 列没有出现 Using index condition。这说明 MySQL 没有把非前缀条件下推到索引层过滤，而是先回表再判断。
常见原因包括：
- MySQL 版本低于 5.6 —— ICP 是 5.6 引入的特性，旧版本（如 5.5）压根不支持
- 使用了
FORCE INDEX或USE INDEX但未显式启用 ICP（某些老驱动或配置会禁用） - 查询走的是主键索引（聚簇索引），而 ICP 仅对二级索引有效 —— 主键索引回表开销小，优化器可能主动跳过 ICP
- 联合索引的前缀列未出现在
WHERE中，导致整个索引未被选中，自然无从下推
LIKE 带前导通配符时 ICP 为何不触发
当写成 name LIKE '%abc' 时，即使 name 在联合索引最左，ICP 也大概率不会生效。
根本原因是：B+ 树索引无法做“后缀匹配”，% 在开头意味着无法定位索引扫描起点，优化器只能全索引扫描（type = index），此时所有行都需读取并判断，ICP 失去下推意义。
能触发 ICP 的典型场景是右模糊：name LIKE 'abc%'，且该列是联合索引的前缀部分。例如索引 (city, name)，查询 WHERE city = 'Beijing' AND name LIKE 'Li%'，name 的 LIKE 条件可下推。
注意：name LIKE '%Li%' 或 name LIKE '%Li' 都无法利用索引顺序性，ICP 不起作用。
联合索引中非前缀字段参与 WHERE，但没下推
比如索引是 (a, b, c)，查询写成 WHERE a = 1 AND c = 3 —— 这里 c 是非前缀字段，但你期望它被下推，结果发现 Extra 仍是空的。
这不是 bug，是优化器行为：
-
b缺失导致索引只能用到a，c实际上成了“跳过字段”，无法在索引树中连续定位 - MySQL 5.7+ 会对这种“跳跃式”条件尝试 ICP，但前提是统计信息显示下推能显著减少回表量；如果预估收益低（比如
c = 3匹配行很多），优化器可能放弃 ICP - 可通过
SET optimizer_switch='index_condition_pushdown=on';强制开启，但不推荐线上盲目开启——它依赖准确的统计信息
为什么 OR 条件会让 ICP 失效
只要 WHERE 中出现 OR，且任一子条件无法走索引，整个索引选择就可能退化为全表扫描，ICP 自然无从谈起。
更隐蔽的情况是：WHERE a = 1 OR b = 2，其中 a 和 b 分别有单列索引，但优化器无法合并两个索引路径（除非是 MySQL 8.0+ 的索引合并优化，且明确启用），最终可能放弃索引、关闭 ICP。
真正能保 ICP 的写法是确保所有 OR 分支都命中同一联合索引的前缀，例如索引 (a, b)，写成：WHERE (a = 1 AND b = 2) OR (a = 3 AND b = 4) —— 此时仍走索引，ICP 可对每个分支内的非前缀条件生效。
ICP 不是开关式功能，它依赖索引结构、查询写法、统计信息和优化器成本估算的共同作用。最容易被忽略的是：你以为加了联合索引就自动启用 ICP，其实它只在“前缀匹配 + 非前缀过滤”这个狭窄窗口内活跃。检查 EXPLAIN 的 Extra 列，比看有没有索引更重要。
