MySQL本地数据库的存储引擎有哪些

记得那会儿，公司有个项目，后台数据量不大，但要求实时更新日志，我就想着试试Memory存储引擎。
结果，项目上线第一天，系统一忙，内存就爆了，整个系统瘫痪了。
这让我突然想到，任何技术选型，都得先评估风险，不能只看表面。
就像那Memory引擎，虽然读写快，但稳定性差，不是所有场景都适合。

Mysql数据库存储引擎有哪些?

说白了，MySQL最常用的就MyISAM、InnoDB、Memory、Merge这四种，选对能省不少事。

InnoDB是绝对主力，支持事务、行级锁，数据安全这块做得特别到位。
去年我们跑那个金融系统项目，订单表全用InnoDB，并发量3 000QPS跑得稳得很，崩溃了还能自动恢复。
另外一点，它聚簇索引的设计特别适合范围查询，比如查某个时间段的数据，速度能快不少。
但你要是搞个超大规模表，InnoDB的行锁可能会拖慢写入速度，这个点很多人没注意。

Memory（也叫Heap）则是极致性能的代表，数据全放内存里，读写速度比InnoDB快一截。
去年有个实时排行榜场景，用Memory做缓存表，秒级更新没问题。
但有个细节挺关键的：内存表重启后会清空，必须配合binlog恢复或者定时导出，否则数据全没了，说实话挺坑的。

MyISAM适合读多写少的场景，比如报表统计这种。
它支持全文索引，搞全文搜索特别方便，但崩溃恢复能力弱是硬伤。
我们去年一个日志系统用MyISAM，后来发现不对劲，因为某次主从同步出问题，表直接挂了半天。

Merge是个特殊存在，能把多个MyISAM表当做一个大表用。
适用于数据量特别大的情况，或者想分散I/O压力。
但操作方式比较绕，子表要手动维护，更新操作还得直接碰子表，用起来不算方便。

我一开始也以为Merge能解决所有大数据问题，后来发现它对开发者的要求太高了，维护成本反而翻倍。
等等，还有个事，DBD（BerkeleyDB）现在基本没人用了，Example更别提，Federated适合分布式架构但网络问题难搞。

建议直接上InnoDB，除了特殊场景（比如纯读缓存用Memory），基本都能覆盖。
但你要是选MyISAM，记得加binlog和定期备份，别等出事才后悔。