您如何选择MySQL数据库引擎

特别是，当MyISAM和InnoDB都不缺少必需的功能时（例如，您不需要外键），如何在MyISAM和InnoDB之间进行选择。

它总是归结为尝试和测量吗？还是在读写次数和频率等方面有良好的经验法则？表格的大小对典型选择有影响吗？

答案是您应该始终进行测量，最好尽可能使用自己的数据和工作量。

由于不同应用程序之间的数据访问模式差异很大，因此很难说，而且不可能为所有工作负载确定“最佳”存储引擎。

但是，上周参加MySQLConf / Percona Performance Conf的MySQL领域取得了令人鼓舞的发展。

一些替代存储引擎：

1. XtraDB（InnoDB的分支）
2. InnoDB插件
3. PBXT
4. 德库

此外，Percona，Google等提供了有助于大大提高InnoDB性能的补丁程序。就个人而言，我运行OurDelta构建。它对我来说效果很好，我鼓励您查看OurDelta和Percona版本。

如果这只是一个简单的存储/报告系统，那么我将使用MyISAM来获得原始性能。

如果我担心多次写入的多个并发访问，可以使用InnoDB来利用行级锁定。

对于不同的MySQL数据库引擎，有很多基准测试。在Percona MySQL Performance Blog上有一个不错的比较MyISAM，InnoDB和Falcon的工具，请参见此处。

在上述两个引擎（MyISAM和InnoDB）之间要考虑的另一件事是它们的锁定方法。MyISAM执行表锁定，而InnoDB执行行锁定。不仅要考虑性能指标，还要考虑很多因素。

出于操作原因，即使您的应用程序并非绝对需要这些功能，您也会发现它们非常有用：

• InnoDB具有MVCC，这意味着您可以进行非阻塞一致备份
• InnoDB具有自动恢复功能，这意味着在异常关闭后无需进行冗长的REPAIR TABLE操作
• 使用InnoDB，读者永远不会阻止作者，反之亦然，这意味着（通常而言）意味着更高的并发性（尽管这在一般情况下并不一定意味着更好的性能）
• InnoDB将其行聚集在主键上，如果主键选择得足够好，则可能意味着读操作的IO操作更少。

因此，尽管有外键约束，您仍然可能仍要使用InnoDB。

当然，这是ServerFault，而不是Stack Overflow，因此正确的答案是：

• 您必须始终使用应用程序开发人员选择的引擎
• 如果他们没有选择特定的引擎，那么他们对使用MySQL并不十分认真，并且可能不知道如何正确使用它。
• 您不能将引擎切换到测试应用程序的引擎，否则可能会引入错误。

我的托管服务提供商建议我们完全摆脱MyISAM，并改用InnoDB，除非不可能。

在我们的案例中，我们的数据严重损坏，每天从几次显示到几次显示，总是需要REPAIR TABLE和相关命令，这在大型表上花费了很长时间。

一旦我们将（或：）转换为InnoDB，问题就立即消失了。我们的缺点/缺点：

• 无法转换具有FULLTEXT索引的表（此问题随着时间的流逝而逐渐消失；它已被基于Solr / Lucene的解决方案所替代，该解决方案的质量仍然更高）
• 具有数百万行的大型表（通常需要COUNT（*））非常慢，我们也无法切换它们。

但请注意：这都是特定于我们的环境等，因此通常可能不适用。