每个应用程序在使用数据库时都有自己的性能配置文件，并且可能会随着时间的推移而改变。

你能做的最好的事情就是测试你的选择。在MyISAM和InnoDB之间切换是很简单的，所以加载一些测试数据并在你的站点上启动jmeter，看看会发生什么。

我知道这不会受欢迎，但我还是这么说:

myISAM缺乏对数据库基本要素的支持，如事务和引用完整性，这通常会导致应用程序出现故障/ bug。如果您的数据库引擎甚至不支持这些基础知识，那么您不可能不学习正确的数据库设计基础知识。

在数据库世界中不使用引用完整性或事务就像在软件世界中不使用面向对象编程一样。

InnoDB已经存在了，使用它吧!尽管myISAM是所有遗留系统的默认引擎，但MySQL开发人员最终还是同意在新版本中将其更改为默认引擎。

不，无论您是在读写还是有什么性能考虑，使用myISAM都会导致各种各样的问题，比如我刚刚遇到的这个问题:我正在执行数据库同步，同时其他人访问了一个访问myISAM表的应用程序。由于缺乏事务支持，这个引擎的可靠性也很差，导致整个数据库崩溃，我不得不手动重启mysql!

在过去15年的开发中，我使用了许多数据库和引擎。在此期间，myISAM在我身上崩溃了十几次，其他数据库只有一次!那是一个microsoft SQL数据库，其中一些开发人员编写了错误的CLR代码(公共语言运行时-基本上是在数据库内部执行的c#代码)，顺便说一下，这并不是数据库引擎的错误。

我同意这里的其他答案，即高质量的高可用性、高性能应用程序不应该使用myISAM，因为它不起作用，它不够健壮或不够稳定，无法带来无挫折的体验。详见Bill Karwin的回答。

附注:我喜欢myISAM的粉丝们投反对票，但不能告诉你这个答案的哪一部分是错误的。

我曾经在一个使用MySQL的大容量系统上工作过，我也尝试过MyISAM和InnoDB。

我发现MyISAM中的表级锁定对我们的工作负载造成了严重的性能问题，这听起来与您的工作负载类似。不幸的是，我还发现在InnoDB下的性能也比我希望的要差。

最后，我通过分割数据解决了争用问题，这样插入就进入了一个“热”表，而选择从不查询热表。

这也允许删除(数据是时间敏感的，我们只保留X天的价值)发生在“陈旧”的表上，这些表同样不会被选择查询触及。InnoDB在批量删除方面的性能似乎很差，所以如果你打算清除数据，你可能想要以这样一种方式来构造它，即旧数据在一个陈旧的表中，可以简单地删除而不是对其进行删除。

当然，我不知道你的应用程序是什么，但希望这能让你对MyISAM和InnoDB的一些问题有一些了解。

myisam对于这种类型的工作负载(高并发写入)是一个NOGO，我对innodb没有那么多的经验(测试了3次，发现每次性能都很糟糕，但自从上次测试以来已经有一段时间了) 如果你没有被强迫运行mysql，可以考虑尝试postgres，因为它处理并发写要更好

我发现即使Myisam有锁争用，它在大多数情况下仍然比InnoDb快，因为它使用了快速的锁获取方案。我尝试了几次Innodb，总是因为这样或那样的原因回到MyIsam。此外，InnoDB在巨大的写负载下会非常消耗CPU。

这个问题和大部分答案都已经过时了。

是的，MyISAM比InnoDB快是无稽之谈。注意问题的日期:2008年;现在已经过去了近十年。从那时起，InnoDB在性能上取得了显著的进步。

戏剧性的图表是MyISAM获胜的一种情况:没有where子句的COUNT(*)。但这真的是你花时间做的事情吗?

如果你运行并发测试，InnoDB很可能会赢，即使是对MEMORY。

如果在对select进行基准测试时执行任何写入操作，MyISAM和MEMORY可能会因为表级锁定而丢失。

事实上，Oracle非常确定InnoDB更好，以至于他们几乎从8.0中删除了MyISAM。

这个问题写于5.1的早期。从那时起，这些主要版本被标记为“一般可用性”:

2010: 5.5(。12月8日) 2013: 5.6(。2月10日) 2015年:5.7(。10月9日) 2018年:8.0(。四月十一日)

底线:不要使用MyISAM