目录
一、原理通俗理解
二、实际工作里的优点
三、工作中踩坑 & 局限性（重点避坑）
1. 不支持的场景，ICP 失效
2. 无法下推到分区表、外键关联查询
3. 字符串编码不一致、排序规则不同
四、日常开发落地经验
五、总结定位
索引下推是MySQL InnoDB 优化器核心优化手段，5.6 及之后默认开启，日常开发、SQL 慢查询优化高频用到，简单概括：把原本回表过滤的条件，下移到索引层先行过滤，大幅减少回表次数。
一、原理通俗理解
联合索引idx(a,b,c)，查询：
select * from t where a=1 and b>10 and c like '%xx';- 无 ICP：引擎根据
a=1、b>10拿到所有主键 ID→回表查整行数据→在 server 层过滤c like '%xx'，无效数据也要回表； - 开启 ICP：存储引擎在索引页直接用 c 字段过滤，不满足 c 条件的数据直接丢弃，只把符合全部条件的主键回表。
核心收益：减少 IO 回表次数，索引能过滤越多数据，性能提升越明显。
二、实际工作里的优点
- 优化范围查询痛点联合索引范围字段后字段无法走索引，开启 ICP 后，范围后的索引列可以在索引层过滤，是优化
in、>、<、between慢 SQL 利器； 例：where name='张三' and create_time>'2025-01-01' and status=1，status 在范围列后，无 ICP 全量回表，有 ICP 索引层筛 status。 - 优化前缀模糊查询
like 'xxx%'可用索引，like '%xxx'本身不能走索引，但如果该字段在联合索引里，ICP 可在索引层过滤部分数据。 - 低成本优化，无需改索引MySQL 默认开启（
optimizer_switch='index_condition_pushdown=on'），不用新增索引、改 SQL 结构，存量 SQL 自动受益。
三、工作中踩坑 & 局限性（重点避坑）
1. 不支持的场景，ICP 失效
- 条件含函数、隐式转换：
left(col,2)='ab'、col=123（字符串字段传数字）无法下推； - 索引字段使用
!=、not in大多无法下推； - 覆盖索引场景：查询字段全在索引里（不需要回表），ICP 没有优化空间，不生效。
2. 无法下推到分区表、外键关联查询
多表 join 时，只有驱动表能使用 ICP，被驱动表不支持。
3. 字符串编码不一致、排序规则不同
字段字符集不一样，条件不能下推，开发建表统一字符集很关键。
四、日常开发落地经验
- 排查 ICP 是否生效
explain select ...，Extra 字段出现Using index condition → ICP 生效；出现 Using where 则是 server 层过滤，没用到 ICP。 - 建索引思路配合 ICP联合索引把等值在前、范围在中、过滤字段在后，利用 ICP 过滤后置字段，少建冗余索引；
- 关闭场景极少只有特殊测试、极少数存储引擎兼容问题才手动关闭 ICP，生产一律保持默认开启。
五、总结定位
索引下推属于隐形性能 buff，属于 MySQL 自带优化，不用开发额外编码，但写 SQL、设计索引时要顺着 ICP 规则写，避免函数、隐式转换破坏下推；大部分慢 SQL 优化中，Using index condition是优质执行计划标志之一。
