---
tags: [笔试, 微派, MySQL, 索引, 数据库]
create time: 2026-05-16 14:45
---

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

## 题目

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

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

<details>
<summary>点击查看答案与解析</summary>

### ✅ 正确答案：**C**

---

### 详细解析

#### 什么是索引下推？

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

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

```mermaid
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 时**:
1. 二级索引只过滤第一个索引列（比如 `name = 'Alice'`）
2. **所有**匹配的行都要**回表**到聚簇索引取完整记录
3. Server 层再检查其他条件（如 `age > 25`）
4. 不满足条件的行被丢弃——但**回表已经发生了**

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

#### 逐项分析

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

#### 适用场景

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

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

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

</details>