MySQL社招面试题：hash索引的数据结构？我居然卡在这！

大家好呀，我是你们熟悉的——热爱技术、热衷吐槽、总在面试路上收割灵魂的程序猿小米，31岁，头发还算健在，爱吃火锅，主攻后端。

最近啊，有个老同事跟我说：

“小米，我面了家大厂，面试官问我：MySQL的 hash 索引底层用的是什么数据结构？我一时语塞，最后只能说是哈希表……然后就没然后了。”

他满脸懊悔，我却忍不住一笑：“你知道，你这个回答，就跟面试官问你你妈是谁，你回答说‘人类’一样啊。”

今天我们就来聊聊这个看似简单但面试场上能“一招封喉”的问题：

MySQL 中 Hash 索引到底是什么？底层数据结构又是什么？

但讲干货之前，我们先来回顾一段我亲身经历的社招故事。

MySQL社招现场：Hash索引的一道送命题

事情发生在去年秋天，我跳槽去面一家金融科技公司。

二面的时候，面试官40岁上下，技术扎实，笑里藏刀。

他看了我简历，说：“小米，你这写着熟悉MySQL索引优化，那我问你个简单的，MySQL里的Hash索引你了解不？”

我当时心想：这题稳了，开局一个哈希表，回答靠想象。

于是我微笑着说：“哈希索引嘛，底层就是哈希表，O(1) 查询，效率高！”

面试官笑了：“嗯？你说的是哪种引擎的 hash 索引？MySQL 的默认存储引擎 InnoDB 不是 B+ 树索引么？”

我嘴角一抽，这才意识到——面试官开始“下套”了！

我赶紧补充：“是是是，InnoDB 默认是 B+ 树。不过 Memory 引擎可以用 hash 索引。”

他笑得更灿烂了：“那你知道 hash 索引具体的结构和特点吗？冲突怎么解决？你了解 MySQL 的实现细节吗？”

我顿时如坐针毡，脑中闪回大学时听不懂的《数据结构与算法》，汗都下来了。

这次社招，我虽然最后勉强过了，但也意识到：

“我虽然知道 hash 是哈希表，但对 MySQL 中 hash 索引的理解，远远不够。”

于是，我决定好好研究这个问题，也想借此机会给大家分享清楚：

什么是 hash 索引？它在 MySQL 中如何实现？底层到底用的是什么？什么时候适用，什么时候不适合？

什么是 hash 索引？一句话概括

Hash 索引，就是基于哈希算法构建的索引结构，用于加快等值查询效率。

它不是 MySQL 特有的，也不是只能出现在数据库里，在我们日常写代码中，HashMap、Redis 的底层都是典型的哈希结构。

哈希结构的特点：

• 根据 key 计算 hash 值，再映射到数组槽位
• 时间复杂度 O(1) 查询超快
• 但不支持范围查询、不支持排序
• 存在 hash 冲突问题，需要解决冲突(如链地址法、开放地址法等)

但问题来了：

MySQL 到底哪里用了 Hash 索引？用的是哪种数据结构？

这就要从存储引擎说起。

MySQL 哪些引擎使用 Hash 索引？

在 MySQL 中，索引的类型和底层实现，和你选用的 存储引擎 息息相关。常见的存储引擎有：

• InnoDB(默认)——用 B+ 树
• MyISAM(老引擎)——也用 B+ 树
• Memory(内存表)——可以选择 Hash 索引或 BTree 索引

也就是说：

只有 Memory 引擎才真正支持 Hash 索引！

如果你建了一个 Memory 表，默认索引类型就是 Hash：

这时主键 id 的索引类型默认就是 HASH。

你也可以手动设置：

那么，重点来了！

Memory 引擎下的 Hash 索引，底层数据结构到底是什么？

Hash 索引的底层结构到底是啥？

我们一般理解 hash 索引底层是“哈希表”。

但你知道哈希表到底长什么样吗？给大家简化画个概念图：

在 MySQL Memory 引擎中，底层实现大致为：

• 开辟一段内存(数组)
• 使用哈希函数将 key 映射到数组的某个 slot(槽)
• 如果多个 key 映射到同一 slot，则通过链表法处理冲突

比如：

• name='小米' 经过 hash 函数，落到 slot 17
• name='小王' 也落到 slot 17
• 此时 slot 17 变成了链表：小米 → 小王

总结一句话就是：

MySQL Memory 引擎下，hash 索引的底层是一个“链式哈希表(chained hash table)”，用链表法处理冲突。

这种结构查询效率在理想情况下是 O(1)，最坏情况是 O(n)，比如所有 key 冲突到了一个链上。

Hash 索引的优缺点分析

优点：

• 查询速度快：等值查询效率高于 B+ 树
• 内存中操作：Memory 引擎本身数据在内存，查询更迅猛
• 插入性能好：不需要维持树结构

缺点：

• 不支持范围查询：你查 id > 1000 它就懵了，B+ 树才行
• 不能做排序操作
• 不稳定性：冲突过多，性能急剧下降
• 内存限制：Hash 表结构只存在于内存，宕机即丢

面试官想听你说的，不只是“哈希表”三个字

这段我想送给所有备战社招的小伙伴：

“面试官不是想听你背定义，而是想知道你是否真正理解技术的实现与适用场景。”

所以你回答 hash 索引时，别只说“哈希表”，试着扩展：

“MySQL 的默认引擎 InnoDB 是用 B+ 树做索引，不支持 hash 索引”

“Memory 引擎支持 hash 索引，它底层是链式哈希表”

“hash 索引适合等值查询，不适合范围查询”

“冲突多了会退化成链表，最坏查询是 O(n)”

“对于排序或范围类查询，建议使用 BTree 索引”

这种回答，面试官听了会心一笑，心里默念：

“嗯，面过的人。”

你需要掌握的知识点

为了让大家记得更牢，我整理一张小抄图，重点如下：

别做“只会说哈希表”的程序员

说真的，这道题并不难，难的是你是否愿意去真正深挖一下背后的底层逻辑。

就像当年我第一次回答“hash 索引是哈希表”时，我也觉得挺完美，直到我看到面试官眼里的“再说点”。

技术就是这样，表面你以为是答案，实则是开始。

最后，送大家一句小米常说的话：

• “学技术，不怕被问倒，怕的是你不想问为什么。”
• 加油，我们下次聊聊 B+ 树索引里的“最左前缀原则”吧！

END

如果你觉得这篇文章对你有帮助，欢迎留言点赞，也可以把它转发给正准备面试的小伙伴。

我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！