a,b两个单独索引，where a=xx and b=xx 走哪个索引？为什么？

面试记录 2026-10-13

题目：a,b两个单独索引，where a=xx and b=xx 走哪个索引？为什么？

难度：medium

标签：db/mysql/index, mysql/index, difficulty/medium

评分：⭐⭐⭐⭐☆（4/5）

我的回答

具体装哪个索引不一定，MySQL 会根据索引的具体区分度以及使用索引的成本来规划优化选择哪个索引去使用。

但是如果这么一个搜索条件的话，并且经常使用，推荐建 A 跟 B 的联合索引，让两个字段都能被使用到，提升效率。

这两个字段 A 跟 B，看优化器选择，哪个区分度高，筛选的成本更少，能取到更少，能在更少的数据集中找到目标结果。一般优化器会选择对应的索引，并不会根据直接查看就会知道使用哪个索引。但是如果使用联合索引，将两个数据字段都使用上，这样就可以保证更好的优化，更少的数据集被选择。

点评

优点：

• 抓住核心：优化器基于区分度 + 成本做选择，不是死规则
• 主动给出优化方案：推荐建 (a, b) 联合索引
• 理解成本模型的本质：选择能筛出"最少数据集"的索引
• 意识到无法预判：不能只看索引就断言走哪个，需要 EXPLAIN 验证

不足：

• 遗漏了 Index Merge（索引合并）：MySQL 5.6+ 对 WHERE a=xx AND b=xx 有 index_merge 优化，可能走两个单列索引 UNION，EXPLAIN 显示 Using intersect(idx_a, idx_b) 或 Using union(...)——但这通常代价高，优化器一般不选
• 未讲优化器成本模型的细节：具体是扫描行数 × 回表成本权衡，回表次数是主要决定因素
• 未讲优化器可能放弃索引走全表：两个索引都不划算时可能全表扫描，比反复随机回表更快
• 未讲索引选择验证方式：EXPLAIN 看 key、type、Extra、rows、filtered 字段
• 未讲强制选择：FORCE INDEX / USE INDEX / IGNORE INDEX（生产慎用）
• 未讲统计信息的重要性：优化器依赖 information_schema.statistics 的 Cardinality，统计信息不全会选错索引
• 未讲索引合并的代价：即使优化器选了 index_merge，通常比单个联合索引慢得多（多次扫描 + 结果集合并）

补充：

• 优化器决策顺序：

1. 估算每个候选方案的扫描行数和回表行数
2. 计算总成本（IO + CPU）
3. 选成本最低的方案；如果都太高就选全表扫描

• 联合索引 (a, b) 为什么最优：一次索引扫描能同时定位 a 和 b，回表次数最少（理想情况是命中就 1 行）
• 单索引选择的常见规律：
• a 区分度高（如订单号）→ 走 a 索引，可能只回表几行
• b 区分度低（如 status）→ 优化器倾向走 a 索引
• a、b 区分度都低（如 gender + status）→ 优化器可能直接全表扫描
• EXPLAIN 关键字段：
• key：实际选择的索引
• rows：预估扫描行数
• filtered：预估过滤后剩下的百分比
• Extra：Using index condition / Using index merge / Using index（覆盖索引）等
• 面试加分点：可以说"我实际线上遇到过优化器选错索引的场景，通过 ANALYZE TABLE 刷新统计信息或者临时 FORCE INDEX 修复"

完整讲解

第一部分：知识重点剖析

核心考点定位：理解 MySQL 优化器的成本模型、掌握 EXPLAIN 关键字段、能给出合理的索引优化方案。

知识点拆解：

1. MySQL 是成本模型优化器（Cost-based Optimizer）

• 不是规则模型，不会"永远走区分度高的索引"
• 会枚举所有候选方案（每个索引、全表扫描），估算每个方案的成本，选最低的
• 成本模型核心公式：成本 ≈ IO 成本 + CPU 成本，其中 IO 成本主要来自回表次数
• 依赖 information_schema.statistics 的 Cardinality（采样估算，可能不准）

1. 单列索引 a、b 各自的成本估算

• 走索引 a：rows_a = total_rows / cardinality_a，然后回表 rows_a 次过滤 b
• 走索引 b：rows_b = total_rows / cardinality_b，然后回表 rows_b 次过滤 a
• 优化器选 rows_a 和 rows_b 里更小的那个
• 回表成本通常比索引扫描大得多，所以优化器极度倾向"命中行数少"的方案

1. Index Merge（索引合并，MySQL 5.6+）

• 对 WHERE a=xx AND b=xx，优化器可以考虑两个单列索引各自扫描后再合并结果
• EXPLAIN Extra 显示：
• Using intersect(idx_a, idx_b)：结果取交集（AND 场景）
• Using union(idx_a, idx_b)：结果取并集（OR 场景）
• Using sort_union(...)：结果排序后合并
• 实际很少被选中：需要扫描两个索引 + 合并结果集，成本通常高于单个联合索引
• 只有当两个索引都覆盖查询所有列（覆盖索引）时，优化器才可能选

1. 为什么联合索引 (a, b) 通常是最好的

• 一次索引扫描能同时定位 a 和 b
• 理想情况：命中就 1 行，回表 1 次
• 相比之下，单索引最坏情况要回表成千上万行过滤另一列
• 结论：经常一起查的字段，必须建联合索引

1. 优化器可能放弃索引走全表

• 场景：两个索引区分度都低（如 WHERE gender='M' AND status=1，扫描 40% + 40% 都超过阈值）
• MySQL 有个经验阈值：预估扫描行数占比 > 30% 时倾向全表扫描（B+ 树扫描不如顺序扫描快）
• EXPLAIN 显示：key=None + type=ALL
• 对策：改查询、改索引、或建复合条件索引

1. 优化器选错索引的常见原因与解决

• 统计信息不准：ANALYZE TABLE t 刷新
• 优化器 bug：MySQL 5.7 之前成本模型有 bug，8.0 大幅改进
• 强制干预：
• FORCE INDEX(idx_xxx)：强制走
• USE INDEX(idx_xxx)：提示但优化器可以忽略
• IGNORE INDEX(idx_xxx)：忽略某个索引
• 风险：索引被删或改结构，SQL 直接生产报错；生产慎用

1. EXPLAIN 关键字段速查

• id：查询序号，同一 id 从上到下执行，不同 id 从左到右
• select_type：SIMPLE / PRIMARY / SUBQUERY / DERIVED 等
• table：查询的表
• type：访问类型，从好到坏：system > const > eq_ref > ref > range > index > ALL
• possible_keys：可能用到的索引
• key：实际使用的索引
• key_len：使用索引的字节数（判断联合索引用到哪几列）
• rows：预估扫描行数
• filtered：预估过滤后剩下的百分比
• Extra：额外信息（Using index 覆盖索引 / Using where 需过滤 / Using index condition ICP / Using filesort 需排序 / Using temporary 需临时表 / Using join buffer 用 join buffer）

第二部分：考察方向与延伸递进

考察方向：

• 深度：能否说清优化器成本模型的核心是"回表次数"权衡
• 广度：能否覆盖 Index Merge、FORCE INDEX、EXPLAIN 关键字段
• 应用：能否给出线上的索引优化方案和选错索引的排查流程

延伸递进面试题：

1. 为什么 Index Merge 很少被优化器选中？

• 解答要点：需要扫描多个索引 + 合并结果集，成本远高于单个联合索引；只有覆盖索引场景才可能划算

1. 优化器选错索引怎么排查？

• 解答要点：先看 EXPLAIN 的 rows 和 filtered，ANALYZE TABLE 刷新统计信息，对比其他索引的实际命中行数，必要时 FORCE INDEX 验证

1. 联合索引 (a, b) 和 (b, a) 有什么区别？

• 解答要点：完全等价的两个索引在 B+ 树层面是不同的物理结构；(a, b) 对 WHERE a=? AND b=? 最优，对 WHERE b=? 也能用（跳过 a）；(b, a) 反过来。通常按查询频率最高的组合建一个就够，第二个查询频率低的话用不上

第三部分：面试者参考回答（口语化）

面试官您好，这个问题我按"优化器怎么选 + 为什么这样设计"来答。

先说优化器怎么选。MySQL 是成本模型优化器，它会枚举所有候选方案——走索引 a、走索引 b、走 Index Merge、走全表扫描——然后估算每个方案的成本，选最低的。成本模型的核心是回表次数：走哪个索引，回表过滤另一列的次数最少，优化器就选哪个。所以两个索引区分度差得多时，优化器会选区分度高、扫描行数少的那个；区分度差不多时可能选谁都不一定，具体要看统计信息和当前负载。

Index Merge 是一种理论上的方案，5.6+ 支持。对 WHERE a=xx AND b=xx 优化器可以考虑走两个单列索引分别扫描再取交集（Using intersect）。但实际很少被选中——需要扫两个索引 + 合并结果集，成本通常远高于单个联合索引。除非两个索引都是覆盖索引才可能划算。

推荐建 (a, b) 联合索引是标准答案。因为联合索引一次扫描就能同时定位 a 和 b，理想情况命中就 1 行，回表 1 次；相比之下走单索引最坏要回表成千上万行过滤另一列。频繁一起查的字段一定要建联合索引，这是最本质的优化。

优化器可能完全放弃索引走全表。如果两个索引区分度都低（比如 WHERE gender='M' AND status=1，两个字段各自筛出 40%），扫描占比超过 30% 时优化器会倾向全表扫描，因为 B+ 树随机 IO 不如顺序扫描快。EXPLAIN 显示 key=None type=ALL 就是这种情况。

排查线上优化器选错索引我会按这个流程：先看 EXPLAIN 的 rows 和 filtered 判断是不是选错了；跑 ANALYZE TABLE 刷新统计信息看有没有变化；如果还是选错，FORCE INDEX 强制走指定索引验证效果。FORCE INDEX 生产慎用——索引被删或改结构 SQL 直接生产报错。8.0 的优化器成本模型比 5.7 精准很多，能少踩坑。

当然，具体走哪个索引不能只看索引就断言，一定要用 EXPLAIN 验证。EXPLAIN 里 key 是实际选择的索引、rows 是预估扫描行数、Extra 里的 Using index 说明是覆盖索引、Using filesort 说明需要额外排序——这几个字段基本能定位大部分优化器决策问题。