icp 仅在 explain 出现 using index condition 时真正生效，依赖二级索引、最左前缀匹配及支持的操作符，且过滤率高时才显著减少回表。
ICP 能显著减少回表次数，但只在特定条件下生效——不是所有带复合索引的查询都会触发它。
EXPLAIN 中看到 Using index condition 才算真正启用 ICP
这是唯一可靠的判断依据。仅靠有联合索引、MySQL 版本 ≥5.6、optimizer_switch 开启 index_condition_pushdown=on 都不保证 ICP 生效。
- 如果
Extra列只显示Using where，说明过滤全在 server 层做，没下推 -
Using index condition表示存储引擎（如 InnoDB）在遍历索引时，已用部分 WHERE 条件做过一轮筛选 - 注意：
Using index是覆盖索引，和 ICP 无关；两者可能同时出现，但含义完全不同
ICP 仅对二级索引 + 某些操作符有效
InnoDB 的 ICP 不作用于聚簇索引（主键索引），且对模糊匹配、函数、表达式等有严格限制。
- 支持的操作符：
=、>、、<code>>=、、<code>BETWEEN、IN()、LIKE（但仅当前缀固定时，如name LIKE '张%'；name LIKE '%张'不行） - 不支持：
!=、NOT IN、IS NULL、列上套函数（如UPPER(name) = 'ZHANG'）、涉及计算的表达式（如age + 1 > 20） - 必须是二级索引：聚簇索引（主键索引）不参与 ICP，因为它的“索引项”就是整行数据，无需回表
联合索引字段顺序直接影响 ICP 是否可用
ICP 只能下推「索引中已包含」且「满足最左前缀匹配后剩余部分」的条件。
- 假设索引是
KEY idx_zip_name_age (zipcode, name, age) -
WHERE zipcode = '100001' AND name LIKE '陈%' AND age > 25→ 全部可下推（zipcode定位范围，name和age在索引中且顺序连续） -
WHERE zipcode = '100001' AND age > 25 AND name LIKE '陈%'→ 仍可下推（优化器会重排条件顺序） -
WHERE zipcode = '100001' AND age > 25→age可下推，但name条件缺失不影响 -
WHERE name LIKE '陈%' AND age > 25→ ICP 不生效（zipcode没出现在 WHERE 中，最左前缀断裂）
ICP 的收益高度依赖数据分布和过滤率
它省的是随机 IO，但前提是“下推后筛掉足够多的索引项”。如果条件过滤效果差，ICP 几乎没用。
- 例如：索引
(status, created_at)，查status = 'pending'占全量 95%，再加created_at > '2025-01-01'也只筛掉 5% → 回表次数从 9500 次降到 9000 次，提升微乎其微 - 反过来，如果
created_at > '2025-01-01'能筛掉 90% 的pending记录，那回表从 9500 次降到 950 次，IO 直接降一个数量级 - 真实压测时，别只看
EXPLAIN输出，务必对比Handler_read_*状态变量（如Handler_read_rnd_next下降才说明回表减少）
ICP 的边界很具体：它不改变索引扫描范围，也不替代覆盖索引，更不解决排序或分组开销。最容易被忽略的是——即使所有条件都满足 ICP 触发条件，优化器仍可能因统计信息不准或成本估算偏差而放弃使用它。验证的唯一方式，永远是 EXPLAIN + 实际执行时间 + 存储引擎层读取指标。
