ICP（索引下推）是MySQL 5.6+的查询优化技术，它将部分WHERE条件（如等值、范围）下推至存储引擎层，在二级索引扫描时直接过滤，减少回表和数据传输；仅对range/ref等索引访问类型生效，且条件须覆盖索引最左前缀连续字段。
MySQL 8.0 的 ICP 默认启用且更激进，但依赖执行计划中 type 为 range/ref 等索引访问类型；5.7 虽支持 ICP，但实际生效条件更苛刻，常被优化器跳过。
ICP 是什么？它在哪一环节起作用
ICP（Index Condition Pushdown）不是“把 WHERE 条件塞进索引”，而是让存储引擎在**索引扫描阶段就过滤掉不满足部分 WHERE 条件的行**，减少回表或读取整行的次数。关键点在于：它只对**二级索引扫描**生效，且仅处理能下推到索引层的条件（比如 col = ?、col IN (..)），不能下推的（如函数、隐式转换、跨列表达式）仍由 Server 层过滤。
典型场景：SELECT * FROM t WHERE a = 1 AND b > 100 AND c LIKE 'x%'，若只有 idx_a_b（a,b），则：
- 5.7：可能只用
a = 1走索引，取出所有a=1的行，再在 Server 层用b > 100和c LIKE过滤 - 8.0：若执行计划显示
Extra: Using index condition，说明b > 100已下推到 InnoDB，在读取索引项时就丢弃不满足的项；c LIKE因不覆盖索引列，仍由 Server 层处理
为什么 EXPLAIN 显示 Using index condition 却没提速
常见错觉是“看到 Using index condition 就一定快”，但实际效果取决于几个硬约束：
- 必须是
type为range、ref、eq_ref等索引访问方式；type: index（全索引扫描）或type: ALL（全表扫描）不触发 ICP - 下推条件必须落在索引定义的**最左前缀连续字段上**；例如索引是
(a, b, c)，WHERE a = 1 AND c = 'x'中c = 'x'无法下推（跳过了b） - 8.0 对隐式类型转换更敏感：若
a是INT，但写成WHERE a = '1'，会导致索引失效，ICP 自然归零 - 5.7 在复合索引 + 多范围条件（如
a IN (1,2) AND b > 10）下，ICP 常被禁用，而 8.0 会尝试启用
如何验证 ICP 是否真实生效
不能只看 EXPLAIN，要结合实际 IO 和执行统计：
- 对比
Handler_read_next和Handler_read_first：ICP 有效时，前者数值应显著低于无 ICP 场景（说明索引层提前剪枝） - 检查
SHOW PROFILE FOR QUERY N中的handler阶段耗时，下降明显才说明 ICP 减少了引擎层遍历 - 8.0 可用
EXPLAIN FORMAT=JSON查看index_condition字段是否非空；5.7 不支持该格式，只能靠Extra字段和性能对比 - 强制关闭测试（仅调试）：
SET optimizer_switch='index_condition_pushdown=off'，观察 QPS 或延迟变化
最容易被忽略的是：ICP 的收益与索引设计强绑定。建了 (a, b) 却总查 WHERE b = ?，再新的 MySQL 版本也救不了——ICP 不是万能加速器，它只放大好索引的价值，不弥补坏设计的缺陷。
