server层二次过滤本质是职责隔离：存储引擎仅按索引捞候选记录，server层执行完整where逻辑；常见触发场景包括索引未覆盖全部条件、含函数/类型转换、模糊右匹配及隐式转换等。
Server层二次过滤的本质是职责隔离
MySQL把“找数据”和“判条件”拆成两件事：存储引擎只管按索引结构捞出候选记录（哪怕带冗余），Server层才负责执行完整的WHERE逻辑。这不是设计缺陷，而是分层架构的必然结果——InnoDB不解析SQL，它只响应ha_innobase::index_read()这类底层接口调用；Server层才是唯一理解age = 26 AND status IN ('active', 'pending')语义的地方。
Using where出现的典型触发点
只要存储引擎返回的记录不100%满足WHERE所有条件，Server层就必须补刀。常见情况包括：
- 索引只覆盖部分条件，比如联合索引
(name, age)，但查询带AND city = 'Beijing'，city不在索引里，引擎无法判断 - 条件含函数或类型转换，如
WHERE YEAR(create_time) = 2024，索引字段create_time本身是datetime，但YEAR()必须由Server层计算 - 模糊匹配非前缀，如
WHERE name LIKE '%san'，B+树无法从右截断定位，引擎只能全量扫描索引项再交由Server层筛 - 隐式类型转换，比如
WHERE user_id = '123'（字段是BIGINT），InnoDB读出的是数字，Server层要先转字符串再比对
ICP开启后为什么有时还带Using where
Index Condition Pushdown不是万能的。即使optimizer_switch里index_condition_pushdown=on，以下情况仍会退化到Server层过滤：
- 条件中混用索引列和非索引列，ICP只能下推索引列部分，剩余条件仍归Server层
- 使用了
OR逻辑且分支涉及不同索引或无索引字段，优化器可能放弃ICP - 索引字段为JSON或空间类型，ICP不支持这些类型的下推
- 查询语句含
SELECT *且表有TEXT/BLOB字段，InnoDB在ICP阶段无法安全跳过这些大字段的读取，干脆不启用ICP
怎么快速判断是不是ICP没生效
看EXPLAIN的Extra列最直接：
- 出现
Using index condition：ICP已生效，过滤发生在InnoDB内，回表次数减少 - 只有
Using where：ICP未参与，所有过滤都在Server层，回表数 = 索引范围扫描的记录数 - 同时出现
Using where; Using index：用了覆盖索引（不用回表），但仍有Server层过滤，说明WHERE里有非索引字段或表达式
真正容易被忽略的是：即使type显示range或ref，只要Extra里有Using where，就代表Server层正在做行级遍历过滤——这部分开销不会体现在磁盘IO里，但会吃CPU和内存带宽。
