索引下推（icp）是mysql 5.6+默认启用的优化机制，无需手动开启；其生效需满足：使用innodb二级联合索引、where含最左前缀匹配及索引中存在但无法用于查找的列、无函数或隐式转换；explain中出现“using index condition”是唯一可靠验证信号。
索引下推不是“额外功能”，而是 MySQL 5.6+ 默认开启的优化行为
它不依赖你手动配置，只要用的是 InnoDB 引擎、有合适的联合索引、WHERE 条件中包含索引列，ICP 就大概率在工作。你不需要“启用”它，反而更该关心它“为什么没生效”。
哪些条件会让 EXPLAIN 显示 Using index condition
这是验证 ICP 是否起作用的唯一可靠信号。但不是所有带索引的查询都会触发它，必须同时满足：
- 查询使用的是二级索引（非主键索引），且是联合索引
-
WHERE中有多个条件，其中一部分能用最左前缀匹配（如索引(a, b, c)，条件含a = ?），另一部分虽不能走索引查找，但字段本身在索引中存在（如b > ?或c LIKE 'x%'） - 条件不能是函数操作或类型隐式转换，比如
UPPER(name) = 'ABC'或age + 1 = 25—— 这些无法下推 - 引擎必须是 InnoDB 或 MyISAM（MyISAM 支持有限，实际几乎只看 InnoDB）
反例：SELECT * FROM user WHERE name = 'Alice' AND gender = 'F'，若索引只有 (name)，gender 不在索引里 → 不可能下推 → Extra 是 Using where，不是 Using index condition。
为什么开了 ICP 却没看到 Using index condition
常见原因不是配置关了，而是优化器主动绕过了它：
- 索引选择错误：优化器认为全表扫描或走其他索引更快，压根没选那个联合索引 → 先确认
key列是否是你期望的索引名 - 统计信息过期：执行
ANALYZE TABLE table_name更新统计后，EXPLAIN结果可能变化 -
LIKE左模糊：lastname LIKE '%etrunia%'无法利用索引做前缀匹配，即使字段在索引里，InnoDB 也不下推这个条件（但lastname LIKE 'etrunia%'可以） - 隐式类型转换：
WHERE zipcode = 95054（数字）对比CHAR(5)字段 → 触发转换 → 下推失效
检查方法很简单：EXPLAIN FORMAT=TRADITIONAL SELECT ...，紧盯 key 和 Extra 两列，缺一不可。
别信 optimizer_switch，真要关它才需要手动干预
SHOW VARIABLES LIKE 'optimizer_switch' 里看到 index_condition_pushdown=on 是默认值，改它毫无意义。真正影响 ICP 生效的是查询写法和索引设计：
- 联合索引字段顺序很重要：
(zipcode, lastname, firstname)能下推lastname LIKE 'A%'，但换成(zipcode, firstname, lastname)就不行 —— 因为lastname不在索引前缀连续段内 - 范围查询会截断后续列的索引查找能力，但 ICP 仍可对它们过滤：
WHERE a = 1 AND b > 10 AND c = 5，索引(a, b, c)下，c = 5无法用于查找，但能被下推过滤 -
Using index condition不代表“全部条件都在引擎层完成”，Server 层仍要处理非索引列、函数、子查询等剩余逻辑
最常被忽略的一点：ICP 减少的是回表次数，不是逻辑结果。哪怕 EXPLAIN 显示用了 ICP，如果最终结果集很大，性能瓶颈可能已转移到网络传输或客户端处理上 —— 别只盯着 Extra 看。
