我尝试在MyISAM和InnoDB表中插入随机数据。结果相当令人震惊。MyISAM插入100万行的时间比InnoDB插入1万行的时间少几秒钟!

有点偏离主题，但为了文档的目的和完整性，我想添加以下内容。

一般来说，使用InnoDB会使应用程序变得不那么复杂，可能也更没有bug。因为可以将所有引用完整性(外键约束)放入数据模型中，所以不需要像使用MyISAM时那样多的应用程序代码。

Every time you insert, delete or replace a record, you will HAVE to check and maintain the relationships. E.g. if you delete a parent, all children should be deleted too. For instance, even in a simple blogging system, if you delete a blogposting record, you will have to delete the comment records, the likes, etc. In InnoDB this is done automatically by the database engine (if you specified the contraints in the model) and requires no application code. In MyISAM this will have to be coded into the application, which is very difficult in web-servers. Web-servers are by nature very concurrent / parallel and because these actions should be atomical and MyISAM supports no real transactions, using MyISAM for web-servers is risky / error-prone.

而且在大多数情况下，InnoDB会表现得更好，原因有很多，其中一个原因是它能够使用记录级锁而不是表级锁。不仅在写比读更频繁的情况下，在大型数据集上有复杂连接的情况下也是如此。我们注意到，对于非常大的连接(需要几分钟)，使用InnoDB表比MyISAM表性能提高了3倍。

我想说的是，在使用MySQL时，InnoDB(使用3NF数据模型，具有引用完整性)应该是默认的选择。MyISAM只能在非常具体的情况下使用。它很可能会执行更少，导致应用程序更大，bug更多。

话虽如此。数据模型是一门很少在网页设计师/程序员中发现的艺术。无意冒犯，但这确实解释了MyISAM被如此广泛使用的原因。

对于一个有更多写和读的负载，你将受益于InnoDB。因为InnoDB提供的是行锁而不是表锁，所以你的select可以是并发的，不仅仅是彼此之间的select，还有许多insert。但是，除非你打算使用SQL事务，否则将InnoDB提交刷新设置为2 (innodb_flush_log_at_trx_commit)。这将为您提供大量原始性能，否则将表从MyISAM转移到InnoDB时会损失这些性能。

Also, consider adding replication. This gives you some read scaling and since you stated your reads don't have to be up-to-date, you can let the replication fall behind a little. Just be sure that it can catch up under anything but the heaviest traffic or it will always be behind and will never catch up. If you go this way, however, I strongly recommend you isolate reading from the slaves and replication lag management to your database handler. It is so much simpler if the application code does not know about this.

最后，要注意不同的表负载。您不会在所有表上都有相同的读/写比率。一些接近100%读取的小表可以负担得起MyISAM。同样地，如果你有一些接近100%写的表，你可能会受益于INSERT DELAYED，但这只在MyISAM中支持(对于InnoDB表，DELAYED子句会被忽略)。

但基准是肯定的。

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

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

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

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

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

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

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

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

对于这样的读写比率，我猜InnoDB会表现得更好。 既然您可以接受脏读，那么您可以(如果您负担得起)复制到一个从服务器，并让您的所有读都到从服务器。另外，考虑批量插入，而不是一次插入一条记录。

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

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

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

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

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