MyISAM 是 MySQL 5.5 前默认引擎，因早期 InnoDB 不成熟、非内置、需手动启用，而 MyISAM 开箱即用、轻量稳定，适配当时读多写少的 Web 场景；5.5 起 InnoDB 成为默认，标志 MySQL 迈向生产级事务数据库。
MyISAM 是 5.5 之前默认引擎，不是因为“它更好”，而是因为 InnoDB 当时还不成熟、不内置、不默认启用。
MySQL 5.5 之前 InnoDB 还没进官方发行版核心
在 MySQL 5.1 及更早版本中，InnoDB 是作为第三方插件提供的，需要手动安装、配置并显式启用（innodb=ON）。很多旧部署甚至压根没装它。而 MyISAM 是编译进 mysqld 的“原生”引擎，开箱即用、零配置、稳定轻量——对早期 Web 应用（静态内容、博客、小论坛）已足够。
- MySQL 官方直到 5.1 才将 InnoDB 升级为“集成引擎”，但仍非默认；
- 5.5 是第一个把
default_storage_engine=InnoDB写死进源码、且 InnoDB 编译为 mandatory（不可禁用）的版本； - 早期 InnoDB 存在明显短板：不支持全文索引（MyISAM 有）、启动慢、内存占用高、配置复杂，DBA 普遍不敢在线上主库贸然切换。
MyISAM 的设计目标匹配了当时的主流场景
2000 年代初的典型 LAMP 应用，特点是读多写少、无强事务需求、数据量不大、运维资源有限。MyISAM 的表级锁、无事务、仅缓存索引等“缺陷”，在这些场景下反而是优势：
-
COUNT(*)直接返回缓存值，响应极快（虽然不准，但当时没人较真）； - 每个表三个文件（
.frm/.MYD/.MYI），备份恢复就是拷文件，运维简单； - 崩溃后虽要
myisamchk，但小表几秒搞定，比 InnoDB 启动时做 crash recovery 快得多； - 对低配服务器友好：
key_buffer_size几十 MB 就能跑得动，而 InnoDB 的innodb_buffer_pool_size设小了就疯狂刷盘。
InnoDB 真正成为默认，是 OLTP 场景倒逼出来的结果
不是 Oracle（2010 年收购 MySQL 后）强行推 InnoDB，而是电商、支付、SaaS 类应用爆发后，MyISAM 的表级锁和无事务彻底扛不住：
- 用户同时下单 → 所有
INSERT INTO orders被串行化，QPS 掉到个位数； - 库存扣减 + 日志写入 + 积分更新必须原子执行，MyISAM 做不到；
- 凌晨自动备份时
FLUSH TABLES WITH READ LOCK，整个站直接卡死半小时； - 主从延迟大时，MyISAM 表在从库
REPAIR TABLE可能丢数据，而 InnoDB 从relay log重放即可保证一致性。
真正容易被忽略的是：InnoDB 成为默认，本质是 MySQL 从“轻量数据库”转向“生产级事务数据库”的分水岭。如果你现在还在用 MyISAM，别问“为什么当年选它”，先确认你的业务是否真的不需要事务、行锁、外键和崩溃可恢复——大多数情况下，答案是否定的。
