---
tags: [MySQL, 联合索引, 最左前缀, 索引失效]
create time: 2026-05-16 00:00
---

# 联合索引与最左前缀

## 概述

联合索引（Composite Index）是将多个列放在同一个 B+ Tree 中组织的索引。它的核心法则是**最左前缀匹配原则**——理解这一点就能避开 80% 的索引设计失误。

## 从"字典查词"理解联合索引

翻开一本中文词典，里面的词条按照**拼音 → 笔画 → 部首**的顺序排列：

1. 先按拼音排序（a, b, c...）
2. 拼音相同时，按笔画排序
3. 笔画也相同时，按部首排序

你想查"爱"字，先翻到拼音 `ai` 的区域（第一列），再找 10 画的（第二列），最后精确定位（第三列）——这就是**最左前缀**的直觉。

反过来，如果有人问"10 画的字在第几页？"——你没法回答，因为 10 画的字**分散在每个拼音区**里，没有连续的区域可以翻到。

> [!QUESTION] 思考
> 联合索引 `idx(a, b, c)` 就像这本字典。条件必须从第一列开始依次匹配，不能"跳着查"。下面我们来看看它的具体结构。

## 联合索引的结构

叶子节点按 a 排序，a 相同时按 b 排序，a 和 b 都相同时按 c 排序：

| a | b | c | data |
|---|---|---|------|
| 1 | 10 | 3 | row1 |
| 1 | 10 | 7 | row2 |
| 1 | 20 | 1 | row3 |
| 1 | 20 | 9 | row4 |
| 2 | 5 | 2 | row5 |
| 2 | 15 | 4 | row6 |
| 3 | 10 | 1 | row7 |
| 3 | 10 | 8 | row8 |
| 3 | 30 | 5 | row9 |

> [!QUESTION] 这意味着什么？
> 联合索引的本质是**多级排序**。你可以把它想象成 SQL 的 `ORDER BY a, b, c`。索引中的数据已经按照这个顺序排好了。

## 最左前缀法则详解

```mermaid
flowchart TD
    IDX["联合索引 idx(a, b, c)"]

    IDX --> U1["✅ WHERE a=1"]
    IDX --> U2["✅ WHERE a=1 AND b=2"]
    IDX --> U3["✅ WHERE a=1 AND b=2 AND c=3"]
    IDX --> X1["❌ WHERE b=2"]
    IDX --> X2["❌ WHERE c=3"]
    IDX --> X3["❌ WHERE b=2 AND c=3"]
    IDX --> U4["⚠️ WHERE a=1 AND c=3"]

    U1 -. "用 1 列" .-> _u1
    U2 -. "用 2 列" .-> _u2
    U3 -. "用全部" .-> _u3
    X1 -. "无效" .-> _x1
    X2 -. "无效" .-> _x2
    X3 -. "无效" .-> _x3
    U4 -. "仅用 a" .-> _u4

    style U1 fill:#00D866,color:#fff
    style U2 fill:#00D866,color:#fff
    style U3 fill:#00D866,color:#fff
    style X1 fill:#EE5A24,color:#fff
    style X2 fill:#EE5A24,color:#fff
    style X3 fill:#EE5A24,color:#fff
    style U4 fill:#FF9F43,color:#000
```

### 为什么 b=2 单独查不了？

```mermaid
graph LR
    subgraph SQ1["✅ WHERE a=1 二分查找定位"]
        direction LR
        A1["a=1 区域连续"] --> A2["直接定位起始行"] --> A3["顺序扫描即可"]
    end

    subgraph SQ2["❌ WHERE b=2 需全表扫描"]
        direction LR
        B1["b=10 在 a=1 下"] --> B4["b=10 在 a=3 下"] --> B2["b=2 散落各处"] --> B3["无法定位起点"]
    end

    style SQ1 fill:#E8F8F5,stroke:#00D866,stroke-width:2px
    style SQ2 fill:#FDEDEC,stroke:#EE5A24,stroke-width:2px
    style A1 fill:#00D866,color:#fff
    style A2 fill:#00D866,color:#fff
    style A3 fill:#00D866,color:#fff
    style B1 fill:#EE5A24,color:#fff
    style B2 fill:#EE5A24,color:#fff
    style B3 fill:#EE5A24,color:#fff
    style B4 fill:#EE5A24,color:#fff
```

B+ Tree 中的数据**先按 a 排序**，只有 a 相同时 b 才有序。单独查 `b=2` 时，满足条件的行分散在不同的 a 值下面，没有连续的 `b=2` 区域可供二分查找——只能全树扫描。

> [!QUESTION] 思考
> 规律是什么？只有匹配了索引的**第一列**，才能继续利用第二列；匹配了前两列，才能利用第三列。条件必须从索引的最左列开始，依次匹配，不能跳过中间列。
> 而对于 `WHERE a=1 AND c=3`，虽然 a 匹配了第一列，但跳过了 b，所以 c 无法走索引。不过别担心，MySQL 优化器足够聪明——它会自动调整 WHERE 条件的顺序来匹配索引，**SQL 中条件的书写顺序不影响索引的使用**。

## 范围查询后的断裂

联合索引遇到范围查询（`>`, `<`, `BETWEEN`, `LIKE 'prefix%'`）后，右侧列的索引失效。

```sql
-- 假设已有联合索引 idx(status, created_at, type)

-- ⚠️ 看起来像用上了 3 个列，实际上 type 不会走索引！
SELECT * FROM orders WHERE status = 'paid'
    AND created_at > '2026-01-01' AND type = 'online';

-- 逐列分析：
--   status = 'paid'    → ✅ 等值匹配，精确定位起始行
--   created_at > ...   → ✅ 范围扫描，划定区间终点
--   type = 'online'    → ❌ 区间内数据未按 type 排序 → 退化为内存过滤
```

> [!QUESTION] 为什么范围查询会打断后续列？
> 一个生活类比：联合索引就像一本按**省份 → 城市 → 区县**排序的通讯录。你可以先翻到"广东省"（等值），再在里面翻"深圳市"（等值），最后找"南山区"——很快。但如果你只知道"某个日期之后创建的订单"（范围），你得到的是一个连续但内部无序的数据段，就像拿到"2026 年之后的广东省所有城市"的名单——这个名单里的区县是乱序的，你没法再按区县快速定位。
>
> 简单说：**范围扫描得到的是一个"连续但内部无序"的区间**，后续列无法利用索引的有序性进行二分查找。

```mermaid
graph LR
    A["等值列 = 定位起点"] -->|"精确找到起始位置"| B
    B["范围列 = 确定终点"] -->|"划定扫描区间"| C
    C["右侧列 = 失效"] -->|"区间内无序"| D["退化为 WHERE 过滤"]

    style A fill:#00D866,color:#fff
    style B fill:#00B6BC,color:#fff
    style D fill:#EE5A24,color:#fff
```

### 实战：调整联合索引的顺序

```sql
-- 场景：订单表常用查询——按状态筛选 + 按时间范围 + 按类型过滤

-- ❌ 原始索引：范围列在中间，后续等值列无法使用
CREATE INDEX idx_sct ON orders (status, created_at, type);
-- 查询 A: WHERE status=? AND created_at>? AND type=?
-- → type 无法用索引（created_at 的范围扫描打断了后续列）

-- ✅ 优化方案 1：将等值列提前
CREATE INDEX idx_stc ON orders (status, type, created_at);
-- 查询 B: WHERE status=? AND type=? AND created_at>?
-- → 三个列全部用上！status 定位起点，type 进一步缩小，created_at 做范围
-- 💡 注意：即使 SQL 写的是 created_at 在前，优化器也会自动调整顺序匹配索引

-- ✅ 优化方案 2：如果两个查询频率差不多，拆成两个索引
CREATE INDEX idx_status ON orders (status);
CREATE INDEX idx_status_time ON orders (status, created_at);
-- 让每个索引专注于它的典型查询模式
```

### EXPLAIN 验证：从 range 到 ref

用 EXPLAIN 对比两种索引的效果：

```sql
-- ❌ 用 idx_sct(status, created_at, type)
EXPLAIN SELECT * FROM orders
WHERE status = 'paid' AND created_at > '2026-01-01' AND type = 'online';
```

```
+----+------+---------------+---------+-------+-----------------+------+----------+-------------+
| id | type | possible_keys | key     | ref   | key_len         | rows | filtered | Extra       |
+----+------+---------------+---------+-------+-----------------+------+----------+-------------+
|  1 | range| idx_sct       | idx_sct | NULL  | ...             | 1280 |    33.33 | Using where |
+----+------+---------------+---------+-------+-----------------+------+----------+-------------+
-- type=range：范围扫描后，type='online' 需要逐行过滤（filtered=33.33%）
```

```sql
-- ✅ 用 idx_stc(status, type, created_at)
EXPLAIN SELECT * FROM orders
WHERE status = 'paid' AND type = 'online' AND created_at > '2026-01-01';
```

```
+----+------+---------------+---------+------------------+---------+------+----------+-------+
| id | type | possible_keys | key     | ref              | key_len | rows | filtered | Extra |
+----+------+---------------+---------+------------------+---------+------+----------+-------+
|  1 | ref  | idx_stc       | idx_stc | const,const      | ...     |   42 |   100.00 | NULL  |
+----+------+---------------+---------+------------------+---------+------+----------+-------+
-- type=ref：等值列全部命中，范围扫描在最后一步，filtered=100%！
```

> [!TIP] 联合索引列序黄金法则
> 1. **等值优先于范围**：等值列放在前面
> 2. **选择性高的列靠前**：区分度大的列（如 user_id）比区分度小的（如 gender）靠前
> 3. **范围列放在最后**：让前面的等值列尽量多命中，范围列最后扫描

## 索引失效的典型场景

以下 5 个场景都会导致索引失效，逐一排查可解决大部分问题。

> [!WARNING] 场景 1：隐式类型转换
> ```sql
> ALTER TABLE users ADD INDEX idx_phone (phone);  -- phone 是 VARCHAR 类型
> SELECT * FROM users WHERE phone = 13800138000;  -- 传入 INT！
> ```
> MySQL 会把 varchar 列隐式转换为 int 再比较——函数作用于列，索引失效。
>
> **解决**：传入字符串 `WHERE phone = '13800138000'`。

> [!WARNING] 场景 2：函数/表达式包裹索引列
> ```sql
> SELECT * FROM users WHERE YEAR(created_at) = 2026;
> ```
> 索引列被函数包裹后，B+ Tree 无法直接定位。
>
> **解决**：改为范围查询 `WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01'`。

> [!WARNING] 场景 3：LIKE 以通配符开头
> ```sql
> SELECT * FROM users WHERE name LIKE '%abc%';
> ```
> 前缀未知，无法利用索引的有序性定位。
>
> **解决**：使用前缀匹配 `LIKE 'abc%'`，或考虑全文索引。

> [!WARNING] 场景 4：OR 条件中有列没有索引
> ```sql
> SELECT * FROM users WHERE email = 'a@x.com' OR phone = '138...';
> ```
> 如果 email 有索引但 phone 没有，整个查询不走索引。
>
> **解决**：给 phone 加索引，或用 `UNION ALL` 拆分为两个独立查询。

> [!WARNING] 场景 5：字符集不一致导致隐式转换
> ```sql
> -- 表 charset=utf8mb4，客户端 charset=gbk → 自动转换
> ```
> 跨字符集连接时，MySQL 需要逐行转换再比较，索引失效。
>
> **解决**：确保连接字符集一致 `SET NAMES utf8mb4`。

### 索引失效决策图

```mermaid
flowchart TD
    Q0{"查询条件是否包含索引最左列?"}
    Q1{"最左列是否被函数/表达式包裹?"}
    Q2{"列类型与传入值类型是否一致?"}
    Q3{"OR 条件中所有列是否都有索引?"}
    Q4{"字符集是否一致?"}
    OK["✅ 索引生效"]
    FAIL["❌ 索引失效，排查修复"]

    Q0 -->|是| Q1
    Q0 -->|否| FAIL
    Q1 -->|否| Q2
    Q1 -->|是| FAIL
    Q2 -->|是| Q3
    Q2 -->|否| FAIL
    Q3 -->|是| Q4
    Q3 -->|否| FAIL
    Q4 -->|是| OK
    Q4 -->|否| FAIL

    style OK fill:#00D866,color:#fff
    style FAIL fill:#EE5A24,color:#fff
```

## 最左前缀的灵活应用

一个设计良好的联合索引可以**同时服务 WHERE、ORDER BY、GROUP BY 三种需求**。

```sql
-- 建索引：idx(status, type, created_at)
CREATE INDEX idx_status_type_time ON orders (status, type, created_at);

-- ── 查询 1：等值 + 范围 ──
SELECT * FROM orders WHERE status = 'pending'
    AND created_at > '2026-01-01';
-- → status 等值定位起点，created_at 范围扫描。type 虽在中间但没用到，不影响前两列生效

-- ── 查询 2：利用 ORDER BY ──
SELECT * FROM orders WHERE status = 'pending'
ORDER BY type ASC;
-- → WHERE 条件锁定了 status='pending' 的子区间，该区间内数据天然按 type 排序
-- → 无需额外 filesort！

-- ── 查询 3：利用 GROUP BY ──
SELECT type, COUNT(*) FROM orders WHERE status = 'pending'
GROUP BY type;
-- → 同上，子区间内 type 已有序，分组可以直接跳过
```

### Go 中利用索引的查询设计

在 Go 后端中，构建查询时应当有意识地按照索引列序组织条件：

```go
// 按索引列序拼接查询条件，确保每个条件都能命中 idx_stc(status, type, created_at)
func buildOrderQuery(status string, orderType string, since time.Time) (string, []any) {
    conditions := []string{"1=1"}
    args := []any{}

    if status != "" {
        conditions = append(conditions, "status = ?")
        args = append(args, status)
    }
    if orderType != "" {
        conditions = append(conditions, "type = ?")
        args = append(args, orderType)
    }
    if !since.IsZero() {
        conditions = append(conditions, "created_at > ?") // 范围列放最后
        args = append(args, since)
    }
    query := "SELECT * FROM orders WHERE " + strings.Join(conditions, " AND ")
    return query, args
}
```

> [!NOTE] 关键理解
> ORDER BY / GROUP BY 能复用联合索引，靠的不是"巧合"，而是 B+ Tree **叶子节点本身有序**这一物理特性。只要 WHERE 过滤条件匹配了联合索引的左侧列，剩余列就是有序的——优化器只是利用了已有的顺序，并没有多做一次排序。

> [!TIP] 一索引多用
> 一个好的联合索引可以同时服务 WHERE、ORDER BY、GROUP BY 三种需求。在设计索引时要考虑查询的整体模式，而不是单一查询。

## 联合索引列序决策表

| 查询模式 | 列序建议 | 示例索引 | 说明 |
|----------|----------|----------|------|
| 等值 + 等值 | 高选择性列在前 | `idx(user_id, status)` | 两个等值条件都能走 ref |
| 等值 + 范围 | 等值列在前，范围列最后 | `idx(status, created_at)` | 等值定位起点，范围最后扫描 |
| 等值 + 等值 + 范围 | 等值列全在前，范围列最后 | `idx(status, type, created_at)` | 让尽量多的等值列命中 |
| 等值 + ORDER BY | 等值列 → 排序列 | `idx(status, type)` | 排序列可复用索引有序性 |
| 等值 + GROUP BY | 同 ORDER BY | `idx(status, type)` | 分组复用索引有序性 |
| 范围 + 范围 | 选择性高的范围列在前 | `idx(created_at, amount)` | 两个范围条件，只能一个走索引 |

> [!QUESTION] 什么时候该拆索引？
> 当两种查询模式的列序**互相矛盾**时（如一个需要 `(a, b, c)`，另一个需要 `(b, a, c)`），与其在同一个索引上做取舍，不如创建两个独立索引，让每个索引专注于它的典型查询模式。但要注意——索引越多，写入开销越大，需要在读写之间找到平衡。

## 关联笔记

- [[hhs/MySQL/03-索引与查询优化/13-聚簇索引与二级索引]] — 聚簇索引本身就是特殊的联合索引 (PK)
- [[hhs/MySQL/03-索引与查询优化/15-EXPLAIN 完全指南]] — 用 EXPLAIN 验证联合索引是否按预期生效
- [[hhs/MySQL/03-索引与查询优化/16-慢查询日志分析]] — 如何从 slow log 中识别索引未命中
- [[hhs/MySQL/03-索引与查询优化/17-查询改写技巧]] — 将失效的查询改写为可利用索引的形式