联合索引是越多越好吗？

面试记录 2026-10-13

题目：联合索引是越多越好吗？

难度：medium

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

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

我的回答

首先明确一点，索引并不是越多越好，索引创建要符合业务需求，因为索引创建跟使用都是需要成本的。

每建立一个索引，都要在插入更新数据的时候进行索引更新，插入跟更新的数据，相应的效率就会降低。所以我们使用索引的时候，或者说使用联合索引，使用索引的时候，要控制我们索引的创建量。

在主业务中去考虑使用哪些索引，而不是所有字段都去建立索引。并且尽可能地选择区分度高或者是有价值的字段去增加设置索引。另外可以考虑联合索引方面的设计是在覆盖索引中使用，减少回表。通过覆盖索引来实现不做回表，一次性把所需的数据展现出来。但是如果涉及的字段太多，并且没有什么查询意义，可能就不考虑这方面的使用。

点评

优点：

• 方向正确：明确回答"不是越多越好"
• 抓住写放大核心：每个索引都要在 INSERT/UPDATE/DELETE 时维护，这是最直接的代价
• 业务驱动：强调"主业务"而非"所有字段"，符合工程最佳实践
• 提到区分度：高区分度字段才值得建
• 想到覆盖索引：能意识到覆盖索引能减少回表
• 知道权衡："字段太多且无查询意义就不建"体现了成本收益思维

不足：

• 未讲空间成本：每个索引都是一份完整的 B+ 树副本，索引越多，磁盘占用越大、Buffer Pool 命中率越低（索引和数据争抢 Buffer Pool）
• 未讲优化器成本：索引越多，优化器估算方案越多，优化时间越长（大表上可能明显）
• 未讲冗余索引治理：(a,b,c) 已存在时 (a,b)、(a) 是前缀冗余；治理手段（schema_unused_indexes、INVISIBLE INDEX）
• 未讲覆盖索引的权衡细节：为了覆盖塞太多列会挤压索引宽度，索引膨胀反而降低缓存命中率；覆盖索引和索引宽度的取舍
• 未讲读写比场景差异：读多写少（报表库、维表）可多建索引；写多读少（日志表、事件流）要克制
• 未讲 8.0 特性：ALTER TABLE t ALTER INDEX idx INVISIBLE 灰度下线、FUNCTIONAL INDEX（表达式索引）、DESCENDING INDEX
• 表述略乱："在覆盖索引中使用"这句语义绕，未清楚说清"把常用查询的 SELECT 列塞进联合索引做覆盖"这个思路

补充：

• 索引成本的三张账单：

1. 写放大：每次写操作要维护所有索引的 B+ 树
2. 空间占用：每个索引一份 B+ 树副本，磁盘 + 内存双份成本
3. 优化器负担：候选方案越多，估算越慢

• 联合索引 vs 多个单索引的取舍：
• (a, b) 一个联合索引 vs (a) + (b) 两个单索引——联合索引空间更省、写放大更低；但单索引能覆盖更多查询模式
• 常用查询模式合并成联合索引，独立查询用单索引
• 覆盖索引的边界：
• SELECT a, b FROM t WHERE a=? AND b=? 走 (a, b) 索引是覆盖
• SELECT a, b, c FROM t WHERE a=? 走 (a, b, c) 是覆盖但索引宽度爆炸
• 权衡：命中率高、数据量小的表适合覆盖，大表慎建过宽覆盖索引
• 治理工具：
• sys.schema_unused_indexes：找 count_star=0 的索引
• performance_schema.table_io_waits_summary_by_index_usage：精确统计
• MySQL 8.0 INVISIBLE INDEX：灰度下线 1-2 周再删

完整讲解

第一部分：知识重点剖析

核心考点定位：考察索引设计中的成本收益权衡思维——不是能不能建，而是值不值得建。

知识点拆解：

1. 索引的三张账单

• 写放大账单：每次 INSERT/UPDATE/DELETE 都要维护每个索引的 B+ 树；一个表 5 个索引，写入成本 ≈ 数据本身 + 5 份索引维护
• 空间账单：每个索引一份完整的 B+ 树副本，磁盘占用 = 数据大小 × (1 + 索引数)；Buffer Pool 命中率 = 有效数据页 / 总页，索引挤占会导致数据页被淘汰
• 优化器账单：优化器枚举所有候选方案估算成本，索引越多评估越慢；百万级大表可能明显影响 QPS

1. 联合索引 vs 多个单列索引的取舍

• (a, b) 一个联合索引：空间省一半、写放大减半、查询 WHERE a=? AND b=? 最优；但只覆盖以 a 打头的查询
• (a) + (b) 两个单列索引：能覆盖 WHERE a=? 和 WHERE b=? 两种独立模式；但空间翻倍、写放大翻倍
• 决策原则：查询模式合并成联合索引；独立模式用单列；避免过度建模

1. 覆盖索引的设计权衡

• 覆盖索引 = SELECT 列全部命中索引，EXPLAIN 显示 Using index
• 优点：省回表，性能提升数倍
• 代价：索引宽度增加，Buffer Pool 命中率下降
• 权衡策略：
• 高频查询 + 结果集小：值得覆盖
• 低频查询 + 结果集大：不值得（回表次数少也扛得住）
• 索引宽度 > 数据行宽的一半：慎建（索引比数据还大）

1. 冗余索引治理（关键工程实践）

• 前缀冗余：(a, b, c) 存在时 (a, b)、(a) 冗余，因为 (a, b, c) 已能覆盖前缀查询
• 完全冗余：(a) 和 (a) 重复
• 反向冗余：(a, b) 和 (b, a) 都能用但用途不同，通常保留一个
• 治理工具：
• sys.schema_unused_indexes：SELECT * FROM sys.schema_unused_indexes 找 count_star=0
• performance_schema.table_io_waits_summary_by_index_usage：细粒度统计
• 灰度下线（8.0）：ALTER TABLE t ALTER INDEX idx INVISIBLE → 观察 1-2 周无 SQL 走这个索引 → DROP INDEX
• 不要直接 DROP：可能有低频 SQL 依赖，直接删生产报错

1. 不同业务场景的索引策略

• 读多写少（报表库、维表、日志查询表）：多建索引，覆盖常见查询
• 写多读少（订单写入、事件流、日志采集表）：少建索引，能不加就不加，靠分区、归档策略代替
• 读写均衡（核心业务表）：精细设计联合索引，冗余治理必须做

1. 8.0 相关新特性

• INVISIBLE INDEX：灰度下线首选
• FUNCTIONAL INDEX：表达式索引，如 INDEX((lower(email)))，让 WHERE lower(email)=? 也能走
• DESCENDING INDEX：降序索引，让 ORDER BY a DESC 直接走索引
• 优化器改进：成本模型比 5.7 精准，能少踩选错索引的坑

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

考察方向：

• 深度：能否讲清"写放大 + 空间 + 优化器"三张账单
• 广度：能否覆盖冗余治理、8.0 新特性、不同场景策略
• 应用：能否给出一套线上索引治理的完整流程

延伸递进面试题：

1. (a, b, c) 已存在时，要不要再建 (a, b)？

• 解答要点：通常不用，前缀冗余。但特殊场景例外：如果业务经常单独查 (a, b) 而不查 c，且 (a, b) 索引更小更省内存，可以保留；否则治理掉

1. 索引太多导致写入变慢，怎么定位是哪个索引拖后腿？

• 解答要点：performance_schema.table_io_waits_summary_by_index_usage 看每个索引的 count_write；结合 SHOW INDEX FROM t 看索引列表；把低使用率的索引 INVISIBLE 灰度观察

1. 覆盖索引 vs 回表索引怎么选？

• 解答要点：命中率高 + 结果集小 + 列少 → 覆盖；命中率低或列多 → 不覆盖，靠 ICP 加速

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

面试官您好，联合索引绝对不是越多越好，我按"三张账单 + 三个策略"来讲。

先说三张账单。第一是写放大，每次 INSERT/UPDATE/DELETE 都要维护所有索引的 B+ 树，5 个索引就是 5 倍维护成本。第二是空间，每个索引一份完整 B+ 树副本，索引多了不但磁盘爆，Buffer Pool 也被索引挤占，命中率下降。第三是优化器成本，候选方案多了优化器估算更慢，大表上 QPS 会有影响。这三笔账加起来，索引是奢侈品，不是必需品。

再说三个策略。第一个是联合索引 vs 单列索引的取舍——常用查询模式合并成联合索引（比如 WHERE a=? AND b=? 建 (a, b) 就够），独立的查询模式才用单列索引。避免把每个字段都单建。第二个是覆盖索引的边界——覆盖索引能省回表是好事，但为了覆盖把所有 SELECT 列都塞进一个索引，索引宽度会爆炸，反而挤压 Buffer Pool。经验值是索引宽度别超过数据行宽的一半。第三个是冗余治理，这块特别容易忽略——(a, b, c) 存在时 (a, b)、(a) 就是冗余，应该删掉。治理工具用 sys.schema_unused_indexes 找 count_star=0 的索引；MySQL 8.0 有 ALTER TABLE t ALTER INDEX idx INVISIBLE，先设为不可见观察 1-2 周，确认没有 SQL 依赖再真删。

最后是分场景策略。读多写少的报表库、维表可以多建；写多读少的订单写入、日志表要克制，能用分区和归档策略就少建索引；核心业务表要精细设计联合索引，冗余治理必须做。

8.0 还有几个特性值得知道：INVISIBLE INDEX 灰度下线、FUNCTIONAL INDEX 表达式建索引（INDEX((lower(email))) 让函数查询也能走）、DESCENDING INDEX 让 ORDER BY a DESC 直接走索引。

当然，我的经验是——索引不是能不能建的问题，而是值不值得建。业务有真实查询模式才建，没查询模式的索引都是浪费，删掉能省资源、少踩坑。