阿里面试：MySQL 一个表最多加几个索引？6个？64个？还是多少？

发布时间：2025-11-04 19:19:41 来源：技术快报 作者：数据库

尼恩说在前面：

在40岁老架构师 尼恩的阿里读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、面试阿里、个个索个还滴滴、表最极兔、多加多少有赞、阿里shein 希音、面试shopee、个个索个还百度、表最网易的多加多少面试资格，遇到很多很重要的阿里面试题：

前几天 小伙伴面试阿里，遇到了这个问题。但是由于 没有回答好，导致面试挂了。

小伙伴面试完了之后，来求助尼恩。那么，遇到 这个问题，该如何才能回答得很漂亮，才能 让面试官刮目相看、口水直流。

所以，尼恩给大家做一下系统化、体系化的梳理，云服务器提供商使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

1. 索引基础 ：一个 表的 "数据目录"

索引就是"数据的目录" ， 想象一下你去图书馆找书，没有目录的话你得一本本翻，有了目录就能直接找到想要的书。

索引就是数据库的"数据目录"，它能帮你快速定位数据。

在MySQL中，索引 是一种特殊的数据结构，通常是B+树，它存储着字段值 和对应记录的主键值。

没有索引时，数据库要执行全表扫描，就像你从图书馆第一本书开始一本本找，WordPress模板数据量越大查询越慢。

有索引后，数据库可以直接定位数据位置，效率提升几十甚至上百倍。

数据量越大， 索引的价值就大， 在百万级、甚至千万级的 表中，有索引的查询可能只需几毫秒，没索引可能要几秒， 甚至更久。

但凡事都有不利的一面，  索引不是万能的，它是以额外存储空间和写入性能为代价换取查询速度的提升，需要权衡利弊。

索引的常见类型 有：

普通索引是最基本的服务器租用索引类型，没有任何限制，允许重复值和空值。

唯一索引要求索引列的值必须唯一，但允许有空值。

主键索引是特殊的唯一索引，不允许有空值，每个表只能有一个。

联合索引是多个列组合的索引，遵循最左前缀原则。

此外还有全文索引、空间索引等特殊类型。

不同类型的索引适用于不同场景，比如用户名适合用唯一索引，文章内容适合用全文索引。

2. InnoDB存储引擎的索引限制

InnoDB存储引擎 是 MySQL  最常用的存储引擎，

InnoDB  作为MySQL5.5后的默认引擎，InnoDB支持事务、行级锁、外键约束等高级功能。

InnoDB   的索引采用聚簇索引（主键索引）  +  非聚簇索引 （二级索引） 结合的结构，主键索引的叶子节点直接存储行数据，这使得主键查询特别高效。

InnoDB还支持MVCC多版本并发控制，大大提高了并发读写性能。

对于大多数业务场景，InnoDB都是最佳选择。

InnoDB是MySQL最常用的存储引擎，它就像一辆高性能跑车，既稳定又快速。

InnoDB存储引擎  索引数量限制

尼恩对索引 使用建议：

根据MySQL官方文档， InnoDB存储引擎  它最多允许 一个表最多   64个二级索引（即非主键索引），

官方文档有说明如下：

image.png

链接如下：

dev.mysql.com/doc/refman/…

InnoDB最多允许64个二级索引（非主键索引）， 当然， 还有 加上1个主键索引，总共65个索引。

那在InnoDB中，一个表，最多可以有 64+1=65 个索引

而对于一个索引，最多有多少列呢？

InnoDB  中，一个 索引  最多 能允许  多少个 列 ？

结论是： 一个 索引最多是16列。

官方文档也是有说明的：

image.png

链接如下：

dev.mysql.com/doc/refman/…

每个索引最多可以包含16个字段，这意味，  可以创建一个包含16个字段的超级联合索引。

但要注意，这些是理论最大值，实际应用中应该远低于这个限制。

索引越多，或者一个索引里边的 列越多，  维护成本越高，特别是对于写入频繁的表，过多的索引会严重影响性能。

通常建议单表索引不超过5-8个，核心查询字段优先建索引。

对于联合索引，字段数最好控制在3-5个以内。

尼恩 建议是 ：  定期使用EXPLAIN分析查询语句，确保索引被正确使用，删除冗余和低效的索引。

3. MyISAM存储引擎的索引限制

MyISAM 是 MySQL早期的默认存储引擎，虽然现在用得少了，但在某些场景下仍有价值。

MyISAM  适合读多写少的场景。

MyISAM 不支持事务和行级锁，但查询速度非常快，特别适合读多写少的场景。

尼恩提示：MyISAM的表级锁在写入时会锁定整个表，不适合高并发写入场景。

MyISAM每个表最多支持64个索引，主键索引不计入此限制。

每个索引最多可以包含16个字段，与InnoDB相同。

MyISAM的索引使用B-tree结构存储，支持前缀索引，可以只对字段的前N个字符建立索引。

MyISAM存储引擎  的 索引 限制 如下：

MyISAM和InnoDB的主要区别包括：

MyISAM不支持事务，而InnoDB支持；

MyISAM只有表级锁，InnoDB支持行级锁；

MyISAM不支持外键，InnoDB支持；

MyISAM的崩溃恢复能力较弱，InnoDB更可靠；

MyISAM的全文索引较早出现，但现在InnoDB也支持了。

选择存储引擎时，如果不需要事务且读多写少，可以考虑MyISAM，否则应该选择InnoDB。

4. 索引数量：少即是多

在数据库设计中，索引数量应该遵循"少即是多"的原则。

过多的索引不仅不能提高性能，反而会带来各种问题。

索引就像书中的目录，一本几百页的书有3-5个目录章节就足够了，如果每页都做一个目录，反而会让查找变得困难。

数据库索引也是如此，需要精心设计，只给真正需要的查询条件建立索引。

日常开发中，一个表设计多少个索引合适呢？

阿里巴巴《Java开发手册》技术文档，单表索引数量建议控制在5个以内, 单个索引的字段数不超过5个。

阿里巴巴《Java开发手册》建议单表索引数量控制在5个以内，这是基于多年实战经验得出的结论。

5个索引对于大多数业务场景已经足够，能够覆盖主要的查询需求。

这个建议不是绝对的，对于特别复杂的业务表可以适当增加，但必须有充分的理由。

规范还建议单个索引的字段数不超过5个，避免创建过于复杂的联合索引。

总之： 适当的索引能提高查询效率，过多的索引会影响数据库表的插入和更新功能。

有些时候，不加索引更合适：

阿里巴巴的《Java开发手册》建议单表索引不超过5个，为啥呢？

因为，索引  太多的  "副作用"  ：

所以，现实中的最佳实践：  5个以内最健康。

5. 索引过多会导致的 "七宗罪"

索引虽然能提高查询速度，但过多索引会带来一系列问题，过度索引带来的性能下降和维护困难 ， 这里 总结为索引的"七宗罪"。

理解 "七宗罪" 问题，有助于我们更好地设计索引策略，避免过度索引带来的性能下降和维护困难。

每次执行INSERT、UPDATE、DELETE操作时，MySQL不仅要修改数据，还要更新所有相关的索引。

索引越多，写入操作就越慢。

特别是在批量导入数据时，索引会显著降低导入速度。

测试表明，一个没有索引的表可能比有10个索引的表写入速度快10倍以上。

对于在线web服务系统（如电商平台、 金融交易平台），过多的索引会导致系统吞吐量大幅下降。

占用空间大：每个索引都要单独存一份数据，就像你为了找书方便，买了10本一模一样的字典放家里

每个索引都需要额外的磁盘存储空间。

对于InnoDB，索引和数据存储在同一个文件中，索引越多，文件越大。

一个包含10个索引的百万级数据表，索引可能占用几GB甚至更多的空间。

这不仅增加了存储成本，还会影响备份恢复的速度。

InnoDB使用 Buffer Pool 缓冲池来缓存数据和索引。

索引太多会占用大量 Buffer Pool  缓冲池空间，导致数据和索引的缓存命中率下降。

当 Buffer Pool  缓冲池无法容纳常用数据时，MySQL就需要频繁地从磁盘读取数据，严重影响性能。

合理的索引数量可以让缓冲池缓存更多热点数据。

在高并发环境下，索引更新会导致锁竞争加剧。

特别是当多个事务同时修改同一索引时，可能出现锁等待甚至死锁。

InnoDB的行级锁虽然缓解了这个问题，但索引太多仍然会增加锁冲突的概率，影响系统并发性能。

MySQL会犯选择困难症：索引太多，MySQL反而可能选错最快的查询路径

当表中有多个索引时，MySQL优化器需要选择使用哪个索引来执行查询。

索引太多会增加优化器做出错误选择的风险，可能导致性能反而下降。

比如优化器可能选择区分度不高的索引，或者错误估计索引的选择性。这时就需要使用FORCE INDEX等提示来强制使用特定索引。

索引越多，数据库维护工作就越复杂。

ALTER TABLE操作会变得更慢，特别是在大表上添加或删除索引可能需要很长时间。

备份恢复也会变慢，因为需要处理更多的索引数据。

此外，监控和管理大量索引也需要更多的时间和精力。

MySQL使用统计信息来优化查询执行计划。

索引越多，收集和维护统计信息所需的时间和资源就越多。

在数据变化频繁的表上，过时的统计信息可能导致优化器选择低效的执行计划。

虽然可以手动分析表来更新统计信息，但这会增加维护负担。

6. 索引使用实战技巧

掌握了索引的基本原理后，尼恩建议大家 需要了解一些索引的实战技巧， 帮助我们在实际项目中更好地设计和使用索引。

大家对于 索引的使用，存在很多误区，其中  最大的误区是认为"索引越多查询越快"，实际上索引过多会降低整体性能。

另一个误区是为所有查询字段都建索引，这会导致索引泛滥。还有人认为联合索引字段顺序无关紧要，实际上顺序对索引效率影响很大。

此外，过度依赖自动创建的索引、不评估索引使用效果、不删除无用索引等都是常见问题。

第一：数据量小的表（如配置表）不需要索引。为啥呢  ？  因为数据量小的表 在查询的时候， 全表扫描可能比索引查找更快。

第二：频繁更新的字段（写多读少的字段），要谨慎加索引。为啥呢  ？ 因为每次更新都需要维护索引。

第三：区分度低的字段（如性别、状态标志），通常不适合单独建索引。为啥呢  ？因为索引效果不明显。

第四：太长的字段（如TEXT）不要加索引。如果一定要加，就要使用前缀索引。

第五： NULL值过多的字段，也不建议 加索引。

索引不是建完就一劳永逸的，需要定期监控和优化。

建议每月至少检查一次索引使用情况，删除无用索引。

使用SHOW INDEX FROM table命令可以查看表的索引信息，包括索引名称、字段、基数等。

通过sys.schema_unused_indexes  视图可以找出长期未使用的索引。

EXPLAIN命令可以分析查询是否使用了合适的索引。

对于数据变化大的表，定期ANALYZE TABLE更新统计信息。

监控索引碎片化程度，必要时重建索引。

建立索引变更评审机制，避免随意添加索引。记录索引变更历史，便于问题追踪。

对于重要系统，可以考虑使用索引管理工具。

7. 索引的真实案例分享

理论结合实践才能更好掌握索引设计，下面分享两个真实案例。

这些案例来自实际项目经验，展示了如何根据具体业务需求设计合理的索引策略，以及不当索引设计可能导致的问题和解决方案。

主键使用自增user_id，保证写入性能。

mobile和email字段建立唯一索引，用于登录和密码找回。

register_time建立索引用于新用户分析。

last_login建立索引用于活跃用户统计。

nickname使用前缀索引支持模糊搜索。

避免为gender等低区分度字段单独建索引。

定期清理不活跃用户的索引条目。

主键使用order_id，分布式系统可以考虑雪花ID。

user_id建立索引支持用户查询。

create_time建立索引支持时间范围查询。

status和payment_type建立联合索引用于订单分析。

避免为price等频繁更新的字段单独建索引。

考虑使用部分索引只索引未完成订单。定期归档历史订单减少索引大小。

8. 总结：索引使用黄金法则

经过前面的详细讲解，我们可以总结出一些索引使用的黄金法则。

记住这些法则可以帮助我们避免常见的索引设计错误，建立高效的数据库结构。

这些法则不是死板的教条，而是指导性的原则，在实际应用中需要根据具体情况进行调整。 

相关文章