图 1：本文封面，点明「可插拔引擎层」与 InnoDB 的默认地位。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料，与任何公司的当前招聘无关。题面只有一句话：MySQL 的存储引擎有哪几种，怎么选？
这道题的淘汰线划得很隐蔽。背出 InnoDB、MyISAM、Memory、Archive 四五个名字，只能算及格边缘；面试官真正想听的是：你能不能说清 InnoDB 和 MyISAM 差在哪几个维度，以及为什么今天建新表几乎不需要犹豫。
核心结论：先记住一句——MySQL 是「SQL 层 + 可插拔引擎层」的两层结构，同一张库里不同的表可以用不同的引擎。
想知道当前服务器支持哪些引擎，一条 SHOW ENGINES 就能看到，输出里 Support 列标 DEFAULT 的那行就是默认引擎。选型问题因此不是「这个库用什么引擎」，而是「这张表该用哪个引擎」。
InnoDB 与 MyISAM 的对比，沿四个维度展开。
维度一：事务。 InnoDB 是事务安全引擎，完整支持 ACID：提交、回滚、崩溃恢复一应俱全，背后靠 undo log 支撑回滚、redo log 支撑持久化。MyISAM 不支持事务，一批写入中途失败，就留下半截已写、半截没写的数据，正确性全靠应用自己兜。
维度二：锁粒度。 InnoDB 用行级锁，并发写不同的行互不阻塞，读写之间还能靠 MVCC 的一致性非锁定读互不打扰。MyISAM 只有表级锁，一个写请求锁住整张表，其他读写全得排队——读多写少还能忍，写入一多就成了瓶颈。
维度三：崩溃恢复。 InnoDB 宕机重启后自动重放 redo log，把已提交的事务追平。MyISAM 崩溃后表可能损坏，得人工检查修复，恢复时间与表大小成正比。
维度四：索引结构。 InnoDB 用聚簇索引，主键索引的叶子节点直接挂整行数据，按主键查一次到位；二级索引叶子存主键值，再回表一次。MyISAM 是非聚簇索引，索引叶子存的是行指针，数据和索引分两个文件，按主键查也得多跳一次。
InnoDB 凭什么成为默认？
把四个维度合起来看就明白了：在线业务的核心诉求是并发写不互相堵、事务保证正确、宕机不丢已提交的数据——这三点 MyISAM 一条都满足不了。所以官方文档的立场非常直接：InnoDB 是默认也是最通用的引擎，除非有特殊用途，否则建表都该用它；MySQL 8.4 里 CREATE TABLE 不写引擎，建出来的就是 InnoDB 表。
MyISAM 和其他引擎还剩哪些角落？
MyISAM 的官方定位是只读或读多写极少的工作负载，比如静态数据、数据仓库类的查询场景，它的表空间占用更小。Memory 引擎把数据全放内存里，查找飞快，但重启即丢，只适合临时计算这类「丢了无所谓」的数据。Archive 是压缩的归档引擎，只适合写入后极少再读的历史数据与审计日志。另外还有 CSV（导入导出交换用）、Blackhole（写了就丢，复制链路里当中继用）等专用引擎。它们的共同点是：都是「特殊用途」，不是通用候选。
图 2：四维对比与 InnoDB 成为默认的原因。
可能的追问。
「既然 InnoDB 全面占优，MyISAM 为什么还活着？」历史存量加上只读场景下更小的存储开销。「Memory 引擎这么快，为什么不把热表都换过去？」它同样是表级锁，且数据不落盘，容量受内存限制，定位本就是临时数据。「同一张表能中途换引擎吗？」可以，ALTER TABLE 换引擎会重建整张表，大表要评估锁表与耗时。
易错点清单。
一，把「MySQL 的引擎」说成全局单选，不知道引擎是表级设置、一个库里可以混用。二，只说 InnoDB「支持事务」，讲不出 undo log、redo log 各管什么。三，以为 MyISAM 只是「不支持事务的 InnoDB」，漏掉表级锁、无崩溃恢复、非聚簇索引三处硬差异。四，面试里推荐 Memory 存业务热数据，忘了它重启即丢、同样是表级锁。
回到面试现场，建议的答题节奏：一句话点出可插拔架构与 SHOW ENGINES，然后沿事务、锁、恢复、索引四个维度对比 InnoDB 与 MyISAM，顺势推出默认引擎的结论，最后用 Memory、Archive 的特殊用途收尾。这个顺序本身就是「从机制到选型」的完整推理，比背结论高一个档次。
你维护的系统里还有跑在 MyISAM 上的表吗？是历史包袱还是真的只读场景？欢迎聊聊。