“MySQL 必须为 WHERE 字段加联合索引” 是高并发场景下 避免全表扫描、锁升级、性能雪崩 的核心原则。但“必须”二字需精确界定：仅当查询条件涉及多个字段且需高效过滤时，才需联合索引。

---

一、核心原理：为什么需要联合索引？

▶ 1. 单列索引的局限性

• 场景：

  -- 单列索引
  CREATE INDEX idx_train ON seats(train_id);
  CREATE INDEX idx_status ON seats(status);
  
  -- 查询
  SELECT * FROM seats WHERE train_id = 100 AND status = 0;
  

• 执行计划：
  • MySQL 只能选择一个索引（如 idx_train）
  • 扫描 train_id=100 的所有行 → 再过滤 status=0
  • 若 train_id=100 有 10,000 行 → 扫描 10,000 行

▶ 2. 联合索引的优势

• 场景：

  -- 联合索引
  CREATE INDEX idx_train_status ON seats(train_id, status);
  
  -- 查询
  SELECT * FROM seats WHERE train_id = 100 AND status = 0;
  

• 执行计划：
  • 直接定位 (100, 0) 的记录 → 扫描行数 = 匹配行数
  • 若匹配 10 行 → 仅扫描 10 行

💡 核心认知：
联合索引 = 多维坐标系，单列索引 = 一维标尺

---

二、三大致命误区

▶ 误区 1：盲目添加所有字段到联合索引

• 错误示例：

  CREATE INDEX idx_all ON seats(train_id, status, seat_no, created_at);
  

• 后果：
  • 索引体积膨胀 → 写性能下降
  • 仅前缀字段有效（如 WHERE status=0 无法用此索引）

▶ 误区 2：忽略最左前缀原则

• 规则：
  • 联合索引 (A, B, C) 仅支持：
    • WHERE A = ?
    • WHERE A = ? AND B = ?
    • WHERE A = ? AND B = ? AND C = ?
  • 不支持：
    • WHERE B = ?
    • WHERE C = ?

▶ 误区 3：认为“有索引就快”

• 场景：
  • status 字段区分度低（如 99% 为 0）
  • 即使有 (train_id, status) 索引，MySQL 可能仍选择全表扫描
• 验证：

  EXPLAIN SELECT * FROM seats WHERE train_id = 100 AND status = 0;
  

  • 检查 type 是否为 ref/range，而非 ALL

---

三、工程实践：联合索引设计四原则

▶ 原则 1：按区分度排序

• 规则：
  • 高区分度字段放左侧（如 train_id）
  • 低区分度字段放右侧（如 status）
• 示例：

  -- 正确：train_id 区分度高
  CREATE INDEX idx_train_status ON seats(train_id, status);
  
  -- 错误：status 区分度低
  CREATE INDEX idx_status_train ON seats(status, train_id);
  

▶ 原则 2：覆盖查询需求

• 场景：

  SELECT id FROM seats WHERE train_id = 100 AND status = 0;
  

• 优化：

  -- 覆盖索引（避免回表）
  CREATE INDEX idx_train_status_id ON seats(train_id, status, id);
  

• 效果：
  • Extra: Using index → 无需访问聚簇索引

▶ 原则 3：避免冗余索引

• 检查：

  -- 冗余：idx_train 已被 idx_train_status 覆盖
  CREATE INDEX idx_train ON seats(train_id);
  CREATE INDEX idx_train_status ON seats(train_id, status);
  

• 清理：

  DROP INDEX idx_train ON seats;
  

▶ 原则 4：监控索引使用率

• 工具：

  -- 查看未使用索引
  SELECT * FROM sys.schema_unused_indexes;
  
  -- 查看索引使用统计
  SELECT * FROM performance_schema.table_io_waits_summary_by_index_usage;
  

---

四、避坑指南

陷阱	破局方案
盲目添加字段	仅包含 WHERE 中的高频过滤字段
忽略最左前缀	查询条件必须包含联合索引的前缀
不验证执行计划	必须用 EXPLAIN 确认索引命中

---

五、终极心法

**“联合索引不是堆砌，
而是坐标的精控——

• 当你 区分度排序，
  你在校准效率；
• 当你 覆盖查询，
  你在消除回表；
• 当你 清理冗余，
  你在铸造纯净。

真正的索引设计，
始于对数据的敬畏，
成于对细节的精控。”

---

结语

从今天起：

1. 多字段 WHERE 必建联合索引
2. 高区分度字段放左侧
3. 用 EXPLAIN 验证索引命中

因为最好的索引设计，
不是盲目添加，
而是精准控制每一比特的坐标。