Using index condition仅表示ICP可能启用，非确认生效；真正生效需对比开启/关闭ICP时Handler_read_rnd_next值是否显著下降。
EXPLAIN里出现Using index condition就代表ICP生效了吗
不是。Using index condition只是ICP可能启用的信号，不是确认生效的证据。它只说明优化器“打算”下推部分条件，但实际是否真减少回表，得看数据分布和条件写法。
常见错误现象是：EXPLAIN显示Using index condition，但rows值远大于最终返回行数（比如rows=8200，结果只有12行），说明大量索引记录仍被回表后才被Server层过滤掉——ICP没覆盖到关键条件。
真正起作用的标志是：Handler_read_rnd_next在开启ICP时明显低于关闭时。这个状态变量统计的是回表次数，下降才说明引擎层确实筛掉了一批记录。
怎么对比确认ICP是否真实起效
用SHOW STATUS LIKE 'Handler_read%'前后对比最直接。操作步骤如下：
- 执行
FLUSH STATUS清空计数器 - 运行目标SQL一次
- 执行
SHOW STATUS LIKE 'Handler_read%'，记下Handler_read_rnd_next值 - 临时关闭ICP：
SET optimizer_switch='index_condition_pushdown=off' - 重复前三步，再对比两次的
Handler_read_rnd_next
如果关闭后该值显著上升（比如从37跳到1942），说明ICP原本确实在减少回表；如果基本不变，说明条件根本没被下推，或者索引结构/写法不满足下推规则。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
哪些WHERE条件会被ICP忽略，导致“假生效”
即使列在索引里，以下写法也会让对应条件无法下推，只能留在Server层过滤：
-
LIKE '%xxx'或LIKE '%xxx%'（前导模糊） -
column != value（部分MySQL版本中!=不参与下推） -
column IS NULL或column NOT IN (…) -
UPPER(name) = 'ABC'这类函数包装 -
name = 'a' OR age = 25（OR分支破坏下推路径）
特别注意：联合索引(a, b, c)上，WHERE b = 2 AND c = 5不会触发ICP，因为缺少a做范围定位，整个扫描无起点，引擎层连“顺路检查”的机会都没有。
为什么Extra同时出现Using index condition和Using where
这表示ICP只承担了部分过滤责任，其余条件仍由Server层兜底。例如索引是(name, age)，查询WHERE name LIKE '张%' AND age = 25 AND city = '北京'：
-
name LIKE '张%'用于索引范围扫描（ref/range） -
age = 25可下推（因在索引中），触发Using index condition -
city = '北京'不在索引里，必须回表后判断，触发Using where
这种混合状态很常见，但容易误判为“ICP全量生效”。真正要盯的是rows与实际结果集的比值——越接近1，说明下推越彻底。
最容易被忽略的一点：ICP只对二级索引有效，主键查询（WHERE id = ?）天然不回表，EXPLAIN里无论有没有Using index condition都跟ICP无关。
