03 - 单选题 1：索引下推（Index Condition Pushdown）

题目

关于 MySQL InnoDB 存储引擎中的索引下推（Index Condition Pushdown, ICP）优化，以下说法正确的是：

选项	内容
A	索引下推可以将条件判断从存储引擎层下推到 CPU 层执行
B	索引下推适用于 ALL（全表扫描）类型的查询
C	使用索引下推可以减少存储引擎访问表的次数（回表次数）
D	索引下推在所有情况下都能提升查询性能

点击查看答案与解析

✅ 正确答案：C

详细解析

什么是索引下推？

在优化器确定了访问数据的读策略（即选择了哪些索引）之后、读取数据之前，如果 WHERE 子句中还有可以利用索引中字段来评估的条件，则把这些条件的评估操作下推给存储引擎层执行，这个技术就叫索引下推。

为什么需要索引下推？（问题背景）

flowchart TD
    subgraph IC["无 ICP — 传统方式"]
        A[二级索引扫描到匹配的行] --> B["回表到聚簇索引获取完整行"]
        B --> C["在 Server 层检查剩余条件"]
        C --> D{"满足条件?"}
        D -->|"否"| E[丢弃该行]
        D -->|"是"| F["返回结果"]
    end

    subgraph IX["有 ICP — 优化后"]
        G[二级索引扫描到匹配的行] --> H["在索引层直接检查剩余条件"]
        H --> I{"满足条件?"}
        I -->|"否"| J["跳过回表"]
        I -->|"是"| K["回表到聚簇索引"]
        K --> L["Server 层再确认"]
        L --> M["返回结果"]
    end
    
    IC -.->|节省回表| IX

没有 ICP 时:

二级索引只过滤第一个索引列（比如 name = 'Alice'）
所有匹配的行都要回表到聚簇索引取完整记录
Server 层再检查其他条件（如 age > 25）
不满足条件的行被丢弃——但回表已经发生了

有了 ICP 后:

二级索引不仅过滤第一个列，还在索引层尝试过滤其余条件
不满足索引列上的条件的行，直接跳过回表
只有同时满足所有索引列条件的行才回表

逐项分析

选项	正误	原因
A	❌	反了！ICP 是将条件从Server 层（CPU 层）下推到存储引擎层。应该是"上推"或题目说反了方向
B	❌	ICP 只在使用二级索引的查询中生效，ALL（全表扫描）不涉及索引，自然没有 ICP
C	✅	正确！这是 ICP 的核心价值——减少不必要的回表操作
D	❌	ICP 需要索引中包含所有用到的列才能发挥效果，而且当回表后的额外过滤代价很低时，收益有限

适用场景

-- 复合索引 (name, age)，ICP 可以发挥作用
SELECT * FROM users 
WHERE name LIKE 'A%' AND age > 25;

-- 此时二级索引能过滤 name 和 age，减少回表

[!tip] 一句话总结索引下推的本质：把能尽早拒绝的行挡在门外，避免无效的回表开销。

3.2 KiB Raw Blame History Unescape Escape