线上慢查询里有一种很容易被误判的情况：EXPLAIN 明明显示用了索引，接口还是慢。很多人看到 key 不为空就放松了，实际上慢点可能藏在回表上。二级索引先扫到一批记录，再回聚簇索引拿整行，如果回表后才发现大部分行不满足条件，成本照样会很高。
Index Condition Pushdown，也就是 ICP，解决的就是其中一部分浪费。它会把能用索引列判断的条件下推到存储引擎，让 InnoDB 在索引记录层面先过滤一遍，减少不必要的回表。官方文档里，ICP 生效时 EXPLAIN Extra 常见提示是 Using index condition。
为什么用了索引还慢
假设订单表有二级索引 idx_user_amount(user_id, amount)，查询如下：
SELECT * FROM orders WHERE user_id = 10086 AND amount > 500 AND status = 'PAID';
user_id 和 amount 都在索引里，InnoDB 可以在二级索引扫描时判断它们；但 status 如果不在索引里，仍然要回表后才能判断。ICP 能减少的是索引层能判断的那部分无效记录，不会让索引外的条件凭空提前过滤。
怎么确认 ICP 生效
先看执行计划，不要只看 possible_keys 和 key：
EXPLAIN SELECT * FROM orders WHERE user_id = 10086 AND amount > 500 AND status = 'PAID';
如果 Extra 里出现 Using index condition，说明优化器选择了 ICP。更稳的方式是用 EXPLAIN ANALYZE 看实际行数和耗时，再配合慢查询统计观察 p95/p99。
用开关做 A/B 验证
排查时我喜欢在会话级别关掉 ICP 做对比：
SET optimizer_switch='index_condition_pushdown=off'; EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id=10086 AND amount>500; SET optimizer_switch='index_condition_pushdown=on'; EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id=10086 AND amount>500;
如果打开后扫描行数和耗时明显下降，说明 ICP 的收益是真实的。如果差别很小，慢点可能在排序、临时表、锁等待、网络返回大结果集，或者本来就需要更好的组合索引。
ICP 不能替代好索引
ICP 是减少回表浪费，不是让坏索引变成好索引。对于核心高频 SQL，如果查询总是按 user_id,status,created_at 过滤和排序，那更直接的方案通常是设计合适的组合索引，甚至做覆盖索引。
我的判断方式很朴素：ICP 能救一段路，但如果这条 SQL 是主链路，就别长期依赖优化器临场发挥。索引设计应该让访问路径稳定、可解释、可压测。
上线检查清单
- 确认查询使用的是二级索引，且部分过滤条件包含索引列。
- 检查
EXPLAIN Extra是否出现Using index condition。 - 用
optimizer_switch做 on/off 对比，不要只看单次 EXPLAIN。 - 观察实际 rows、执行时间、慢查询分位和回表相关指标。
- 如果返回列很多且回表仍重，评估覆盖索引。
- 如果慢点来自锁等待或排序临时表，不要把锅甩给 ICP。
我的经验结论
ICP 是 MySQL 优化器里很实用但容易被忽略的一环。它不会改变业务 SQL 的语义，也不会替你重建索引；它只是把能提前判断的索引条件尽量提前判断。
所以看到“用了索引还慢”时，我会先问：回表前过滤了多少？ICP 有没有生效？如果生效后仍然慢，再去看组合索引、覆盖索引、排序和锁等待。这个顺序比只盯 possible_keys 靠谱得多。
