icp是否真起作用，关键看handler_read_rnd_next值在关闭icp后是否明显上升；若explain显示using index condition但rows远大于结果集，或同时出现using where，说明仅部分条件被下推。
ICP 能显著减少回表，但前提是条件列必须在二级索引中且满足下推规则；否则 EXPLAIN 里即使显示 Using index condition，实际也可能是“假生效”。
怎么看 ICP 是否真在起作用？
关键不是看有没有 Using index condition，而是结合 rows 和实际回表量判断：
-
rows值远大于最终结果集（比如rows=5000，但只返回 20 行），说明大量中间结果被 Server 层过滤了——ICP 没覆盖到这部分条件 - 如果
Extra同时出现Using index condition和Using where，说明只有部分条件下了推，剩余仍由 Server 层处理 - 用
SHOW STATUS LIKE 'Handler_read%'对比开启/关闭 ICP 时的Handler_read_next和Handler_read_rnd_next：后者下降明显才代表回表减少
哪些 WHERE 条件能被 ICP 下推？
不是所有带索引列的条件都能下推，InnoDB 只支持特定运算符和结构：
- 支持：
=、!=、、<code>、<code>>、>=、BETWEEN、IN（单值或小范围）、LIKE 'xxx%'（非前导模糊） - 不支持：
LIKE '%xxx'、LIKE '%xxx%'、NOT IN、IS NULL、函数调用（如UPPER(name)）、子查询、OR连接的多个条件 - 特别注意：
!=在某些 MySQL 版本中虽语法合法，但实际不参与下推，仍走 Server 层过滤
为什么联合索引顺序影响 ICP 效果？
ICP 只能在索引扫描路径上“顺路”检查字段，不能跳过前缀列：
- 索引是
(a, b, c)，查询WHERE a = 1 AND c = 5：ICP 可下推c = 5，因为a = 1已锁定索引范围，c是该范围内的可访问列 - 同样索引，查询
WHERE b = 2 AND c = 5：无法使用a定位范围，整个索引扫描无起点，ICP 失效，b和c都只能 Server 层过滤 - 索引是
(dept_id, emp_name)，而WHERE dept_id = 10 AND emp_name LIKE '%张%'：前导模糊导致emp_name无法用于范围扫描，ICP 对它无效——哪怕它在索引里
如何验证并强制让 ICP 生效？
不要依赖默认行为，主动确认和干预：
- 用
SELECT @@optimizer_switch检查index_condition_pushdown是否为on（MySQL 5.6+ 默认开启，但可能被手动关掉） - 对关键查询加
FORCE INDEX(idx_name)避免优化器选错索引，确保走的是含目标列的二级索引 - 若发现
LIKE '%xxx'拖慢性能，考虑改用倒序存储 +REVERSE()索引，或引入全文索引、Elasticsearch 等外部方案 - 最易忽略的一点：ICP 只作用于二级索引；主键查询（
WHERE id = ?）天然不回表，谈不上 ICP——别在聚簇索引上浪费调试时间
