用explain analyze观察icp是否生效：先看是否有“index condition pushdown”或“filtered: x.x (index condition)”，再对比rows_read与rows_examined，若后者显著更大则icp未生效。
如何用 EXPLAIN ANALYZE 观察 ICP 是否生效
MySQL 8.0 默认启用索引下推（ICP），但实际是否触发，不能只看 EXPLAIN 的 Extra 字段里有没有 “Using index condition”——这个字段在旧版本就存在，且可能误报。真正可靠的方式是执行 EXPLAIN ANALYZE，它会真实运行语句并返回各阶段耗时与行数过滤细节。
关键看输出中扫描索引后、回表前的过滤动作是否发生在存储引擎层：
- 如果看到类似
-> Filtered: 10.00 (index condition)或明确标注index condition pushdown的子节点，说明 ICP 生效 - 如果只有
-> Filtered: 100.00 (table condition)，说明条件被上推到 Server 层过滤，ICP 实际未参与 -
rows_examined明显高于rows_read（尤其在二级索引 + WHERE 多条件时），大概率是 ICP 没起作用，导致更多索引项被读取后才过滤
哪些 WHERE 条件会导致 ICP 失效
ICP 不是万能的，MySQL 只对满足特定结构的索引列条件做下推。常见失效场景包括：
- 对索引列使用了函数或表达式：
WHERE YEAR(create_time) = 2023→create_time索引无法下推年份计算 - 隐式类型转换：
WHERE user_id = '123'（user_id是BIGINT）→ 字符串转数字操作阻止 ICP - 使用了不支持下推的函数：
WHERE status IN ('a','b') AND JSON_CONTAINS(data, '"active"')→JSON_CONTAINS无法下推 - 联合索引中，范围查询后出现等值条件：
INDEX (a, b, c)，查询WHERE a = 1 AND b > 10 AND c = 5→c = 5无法下推，因b > 10已中断索引有序性
为什么 force_index 有时反而让 ICP 失效
强制指定索引看似可控，但可能破坏 MySQL 对 ICP 可用性的判断逻辑。例如：
- 你
FORCE INDEX (idx_a_b_c)，但该索引并不包含 WHERE 中所有可下推的列（比如漏了d），MySQL 为保语义正确，可能放弃 ICP，改用全索引扫描 + Server 层过滤 - 索引统计信息陈旧（
ANALYZE TABLE未更新），优化器误判该索引“不适合下推”，而FORCE并不会重校准这个判断 - 某些存储引擎（如 MyISAM）根本不支持 ICP，即使加了
FORCE，EXPLAIN ANALYZE也绝不会显示 index condition pushdown
验证方法：去掉 FORCE，对比两次 EXPLAIN ANALYZE 输出中 index condition 出现位置和 rows_read 数值变化。
ICP 生效但性能没提升？检查这几个点
ICP 成功下推 ≠ 查询变快。以下情况会让 ICP “做了但白做”：
- 索引本身选择性差（如
status TINYINT只有 3 个值），即使下推了status = 1，仍需扫描大量索引页，IO 压力未减 - 启用了
query_cache_type = 1（已弃用但线上偶见），可能导致EXPLAIN ANALYZE走缓存而非真实执行路径 - 表使用了压缩行格式（
ROW_FORMAT=COMPRESSED），部分条件下 ICP 过滤逻辑需解压后才能判断，实际延迟转移到存储引擎内部 -
innodb_stats_persistent = OFF且数据变动频繁，索引统计不准，优化器选错索引，ICP 根本没机会触发
最易被忽略的是：ICP 只减少 **索引页内无效记录的读取**，不减少索引页本身的随机 IO。如果瓶颈在磁盘寻道，而不是记录过滤，那看到 “Using index condition” 也没用。
