大家好，我是小米，一个31岁、混迹在Java与数据库之间的搬砖程序员，日常最大的爱好，就是在工作中被数据库折腾、被面试官盘问、然后回家写公众号吐槽+总结。
今天要分享的，是我上周在一次MySQL社招面试中遇到的一个“灵魂拷问”：
“你能讲讲 MyISAM 和 InnoDB 在索引上的区别吗？”
乍一听是不是挺简单？我当时心里想，不就是主从索引结构不一样、事务支持不同嘛。但面试官嘴角一挑：
“我不想听教材上的那几句话，你就从底层讲起，说说你理解得有多深？”
我当时脑子一热，故事就开始了……
故事从一次表锁开始
几个月前，团队在接入一个老项目，数据库是 MySQL 5.5，表引擎几乎清一色 MyISAM。某天上线后，运营同事找来，说订单系统突然卡死。
排查了半天才发现，是一个 SELECT COUNT(*) 卡住了！
因为这张订单表正好在做一批数据更新操作，MyISAM 是表级锁，读写互斥，导致 SELECT 直接被挂起，直到 UPDATE 完成才释放锁。
那一刻我才真切地意识到：
“索引不是简单的加速查询，背后还有锁机制、事务控制、甚至崩溃恢复的哲学。”
面试中我就从那次事故讲起，面试官眼神微亮，我继续深入：
索引结构的根本差异
- InnoDB 的主索引是聚簇索引（Clustered Index） ，数据和主键是合在一起存储的，顺序是按主键排列。
- 而 MyISAM 是非聚簇索引（Non-clustered） ，索引和数据是分离存储的，索引文件记录的是数据文件的物理地址。
举个栗子：
假设有如下表：
InnoDB 中的主键索引 id，索引结构里就存着 id 对应的整行数据。而 MyISAM 中的索引结构只存 id -> 文件地址，查数据还得再去磁盘读一遍。
这就带来一个经典区别：
- InnoDB 的 主键查找快，但 二级索引慢（要回表）；
- MyISAM 的所有索引都要 二次读取，但结构简单。
二级索引的差异
InnoDB 的二级索引（非主键）里，存的不是物理地址，而是主键值！
查的时候要：
- 先从二级索引查到主键
- 再从主键索引回表取数据
这叫“回表”。
MyISAM 就简单多了，二级索引里直接就是物理地址，查数据快，但不支持事务、数据不安全（稍后讲）。
支持的锁类型不同
- InnoDB：行级锁，并发高，支持事务；
- MyISAM：表级锁，并发低，不支持事务。
在那次订单挂死的事故中，如果用的是 InnoDB，就算某行在更新，其他行的 SELECT 依然能正常读。
而 MyISAM 就像一个“开门写字的人”，别人得等你写完才能进来。
COUNT(*)的速度差异
MyISAM 有个优势，在没有 WHERE 条件时，SELECT COUNT(*) 非常快！
因为它会维护一个行数的计数器，直接返回。
InnoDB 就麻烦了，它必须扫一遍表，看一共有多少行，哪怕你只是查 COUNT(*)。
所以很多时候 InnoDB 的大表 COUNT 查询很慢，要配合业务手动维护行数缓存。
索引缓存机制不同
InnoDB 的索引（包括数据）是存到 缓冲池 Buffer Pool 里的，是统一管理。
MyISAM 是把索引文件放到 Key Buffer 中，数据文件无法缓存在内存中，只能从磁盘读。
也就是说：
MyISAM 的数据访问更依赖磁盘 I/O，InnoDB 更容易做“内存命中”，效率高。
支持外键与事务的区别
InnoDB 是事务型存储引擎，支持：
- ACID 特性（原子性、一致性、隔离性、持久性）
- 外键约束
- 多版本并发控制（MVCC）
MyISAM 什么都不支持，崩了就崩了。
还记得我当年开发一个课程商城系统，学员退款时突然断电重启，MyISAM 表直接损坏，修复表都找不到工具。那之后我就再也不敢用它。
MyISAM 到底还有没有存在的意义？
很多朋友都问，现在都 2025 年了，MyISAM 不都淘汰了吗？
其实也不完全。
它仍然适合一些只读多、写少、数据更新不频繁的场景，比如：
- 历史日志归档库
- 报表分析类应用
- 临时统计表
因为它结构简单、读性能不错，行数统计快，占用空间小。
但只要有事务、有并发、有业务逻辑，请一定用 InnoDB！
MyISAM 和 InnoDB 索引总结大全（面试背诵版）
最后，我在面试中总结了以下 20 个关键词，强烈建议收藏复习：
面试不在乎记住细节，而在乎是否“理解底层”
很多人准备 MySQL 面试题，喜欢背诵：“MyISAM 不支持事务、InnoDB 有聚簇索引……”
但当面试官反问一句：“为什么 MyISAM 不支持事务？那它的索引底层是怎么存的？”很多人就懵了。
其实真正掌握这些原理，不是为了面试，而是为了写出更可靠、更高性能的代码。
比如：
- 用 COUNT(*) 就用 MyISAM？
- 做大表更新要考虑表锁？
- 是不是所有索引都适合加？
如果你曾踩过坑，就会理解——技术的深度，决定了我们写代码的高度。
最后的话
以上就是我一次面试中关于 MyISAM 与 InnoDB 索引区别的分享。
我知道现在用 MyISAM 的场景已经越来越少了，但正因为稀有，才更值得你掌握。当面试官问到这个冷门问题时，你能讲出背后的原理与思考，就已经赢了一半！
END
如果你读完有收获，点个在看 ，别让小米一个人讲故事！
我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
