icp是mysql 5.6+对二级索引查询的关键优化，将where中可下推的索引列过滤条件移至存储引擎层执行，显著减少回表次数；生效需满足：innodb二级索引、条件列属该索引、优化器判定代价更低；explain中出现“using index condition”即确认启用。
MySQL 5.6+ 默认启用的 Index Condition Pushdown（ICP）不是“锦上添花”的可选项，而是对复合索引查询性能有实质影响的关键开关——尤其当 WHERE 中包含非最左前缀的、能被索引字段承载的过滤条件时，它能直接减少回表次数，而非仅仅“稍微快一点”。
ICP 什么时候真正起作用
ICP 不是所有带索引的查询都触发。它只在满足以下全部条件时才生效：
- 存储引擎是
InnoDB或MyISAM（MyISAM支持有限，实际以InnoDB为主） - 使用了**二级索引**（聚簇索引不参与 ICP）
-
WHERE条件中，有**部分谓词可下推到索引层评估**，且这些列属于该二级索引的组成部分（哪怕不是最左前缀） - 优化器判定下推后整体代价更低（例如
name LIKE '%John%'在(age, name)索引中虽不能用LIKE做范围跳查，但可在索引页内逐条检查name字段值）
典型无效场景：SELECT * FROM t WHERE a = 1 AND b > 10 AND c + 1 = 5 —— 表达式 c + 1 = 5 无法下推，因为索引里存的是原始 c 值，不是计算结果。
如何确认 ICP 是否生效
别猜，用 EXPLAIN 看执行计划里的 Extra 字段：
- 出现
Using index condition→ ICP 已启用并参与过滤 - 只有
Using where→ 过滤全在 server 层做，没下推 - 同时出现两者（如
Using index condition; Using where）→ 部分条件下推，剩余仍在 server 层过滤
示例：
EXPLAIN SELECT * FROM user WHERE zipcode = '100001' AND name LIKE '%陈%';
若 idx_zip_name(zipcode, name) 存在，且 MySQL 版本 ≥ 5.6，则大概率看到 Using index condition；若强制关闭 ICP：SET optimizer_switch='index_condition_pushdown=off';，再执行 EXPLAIN，Extra 会退化为 Using where。
ICP 对回表次数的影响有多直接
回表本质是随机 IO，而 ICP 的价值就体现在“少回几次”上：
- 无 ICP：扫描所有
zipcode = '100001'的索引项（比如 1000 条），全部回表取完整行，再在 server 层逐行判断name LIKE '%陈%'→ 1000 次回表 - 有 ICP：扫描
zipcode = '100001'的索引项时，当场检查name字段值 → 只有其中 3 条匹配'%陈%'→ 仅 3 次回表
注意：ICP **不会改变索引扫描范围**（仍按最左前缀匹配），它只是在扫描过程中多做一次字段值判断。所以 name LIKE '陈%' 和 name LIKE '%陈%' 在 ICP 下效果一致——都能下推，但前者还能利用 B+ 树做范围查找，后者只能全量扫描该 zipcode 分支下的所有索引节点。
容易被忽略的兼容性与配置细节
ICP 默认开启，但某些场景下它会被静默绕过：
- 查询中含
SELECT *且索引非覆盖索引 → 正常触发 ICP；但若改用SELECT zipcode, name，而索引恰好是(zipcode, name)，则变成覆盖索引查询，Using index出现，ICP 不再需要（因为根本不用回表） - 使用了
STRAIGHT_JOIN或强制索引（USE INDEX）时，优化器可能跳过 ICP 决策逻辑 -
optimizer_switch中index_condition_pushdown必须为on（默认是），但若被批量脚本或 ORM 自动设为off，ICP 就失效 - 分区表中 ICP 行为更复杂，部分分区可能不支持，需逐个验证
真正关键的不是“有没有 ICP”，而是你是否清楚：当前这条慢查询，它的过滤条件里哪些字段其实在索引里、能否被下推、以及 EXPLAIN 里到底有没有那个 Using index condition —— 其他所有调优动作，都该建立在这个事实判断之上。
