EXPLAIN ANALYZE必须对比加/不加FORCE INDEX的输出：加FORCE后若rows_examined显著高于rows_read、Filtered变为(table condition)或缺失index condition pushdown，说明ICP失效；真正验证ICP是否生效需依赖EXPLAIN ANALYZE的真实执行数据，而非仅看EXPLAIN中“Using index condition”。
EXPLAIN ANALYZE到底要不要加FORCE INDEX
别盲目加FORCE INDEX——它常让EXPLAIN ANALYZE显示的ICP（索引下推）直接消失。MySQL优化器在真实执行时，会基于统计信息和条件判断是否启用ICP；而强制指定索引后，若该索引不包含所有可下推的列（比如WHERE里用了status和create_time，但强制的索引只含status），优化器为保语义正确，会退回到Server层过滤，不再下推。
实操建议：
- 先跑一次不带
FORCE INDEX的EXPLAIN ANALYZE，记下rows_read和是否有index condition pushdown字样 - 再加
FORCE INDEX跑一遍，对比rows_read是否明显上升、Filtered是否变成(table condition) - 如果
ANALYZE输出里rows_examined > rows_read且差距大（比如10倍以上），基本说明ICP没生效，优先检查索引覆盖和条件写法，而不是硬上FORCE
看到“Using index condition”就代表ICP生效了？
不是。MySQL 5.7起EXPLAIN的Extra字段里出现Using index condition，只表示优化器“计划”用ICP，不等于实际执行时真用了。真正验证必须靠EXPLAIN ANALYZE，因为它会真实走一遍存储引擎流程。
关键看输出里的两处：
- 有没有类似
-> Filtered: 5.00 (index condition)这样的行——括号里是index condition才对 - 有没有明确子节点标着
index condition pushdown（树形格式下更清晰） -
rows_read（引擎读取的索引行数）和rows_examined（最终送到Server层的行数）是否接近；如果rows_examined远大于rows_read，说明大量行被读上来才过滤，ICP实际失效
哪些WHERE写法会让ICP在EXPLAIN ANALYZE里“隐身”
ICP不是自动触发的，它对WHERE条件结构很敏感。哪怕索引建得完全正确，写法不对照样白搭。
常见踩坑点：
- 对索引列用函数：
WHERE YEAR(create_time) = 2023→create_time索引无法下推年份提取 - 隐式类型转换：
WHERE user_id = '123'（user_id是BIGINT）→ 字符串转数字操作阻断ICP - 联合索引中范围查询后跟等值：
INDEX (a, b, c)，查WHERE a = 1 AND b > 10 AND c = 5→c = 5无法下推，因b > 10已中断索引有序性 - 用了不支持下推的函数：
JSON_CONTAINS(data, '"active"')、REGEXP、FULLTEXT等，这些统统进不了存储引擎层
EXPLAIN ANALYZE输出里rows_read和rows_examined差太多怎么办
这是ICP失效最直观的信号。比如rows_read = 10000，rows_examined = 9800还算正常；但如果rows_read = 10000，rows_examined = 500，说明95%的索引行被读上来又丢弃了——ICP没干活，全靠Server层硬筛。
排查路径要按顺序来：
- 先确认MySQL版本是否≥8.0.18（
EXPLAIN ANALYZE功能完整支持起点） - 用
SHOW INDEX FROM table_name核对索引列顺序和类型，确保WHERE条件能对齐最左前缀 - 把WHERE条件逐个拆开测试：先
a = ?，再a = ? AND b = ?，再加c > ?，观察EXPLAIN ANALYZE中index condition何时消失 - 注意
ANALYZE TABLE table_name是否近期执行过——陈旧的统计信息会让优化器误判ICP可用性
ICP本身不保证性能提升，但它失效时，几乎一定意味着查询效率有硬伤。重点不是“怎么让它显示生效”，而是“为什么条件写法或索引设计没给它留出入口”。
