你如何select一个MySQL数据库引擎

答案是你应该总是测量，如果可能的话最好用自己的数据和工作量。

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

然而，上周参加MySQLConf / Percona Performance Conf的MySQL领域有非常令人鼓舞的发展。

一些替代存储引擎：

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

另外，Percona，Google等也提供了补丁，对InnoDB的性能有很大的帮助。 就我个人而言，我运行一个OurDelta构build。 它对我很好，我鼓励查看OurDelta和Percona版本。

如果这只是一个简单的商店/报告系统，我使用MyISAM来实现其原始性能。

我会使用InnoDB，如果我担心多个并发访问与大量的写入，以利用行级locking。

有不同的MySQL数据库引擎有很多的基准。 在Percona MySQL性能博客上比较MyISAM，InnoDB和Falcon是一个很好的例子 ，请看这里 。

上述两个引擎（MyISAM和InnoDB）之间需要考虑的另一件事是它们的locking方法。 MyISAM执行表locking，而InnoDB执行行locking。 有各种各样的事情要考虑，不仅是彻头彻尾的performance数字。

有一些function，你会发现非常有用的，因为操作的原因，即使你的应用程序不绝对需要他们：

• InnoDB有MVCC，这意味着你可以采取非阻塞一致的备份
• InnoDB具有自动恢复function，意味着在不清洁的关机后，不会有冗长的REPAIR TABLE操作
• 对于InnoDB，读者不会阻止写作者，反之亦然，意味着（一般来说）更大的并发性（这并不意味着在一般情况下更好的性能）
• InnoDB在主键上对其行进行聚类，这可能意味着读取操作的IO操作更less，如果主键被select得足够好的话。

所以，尽pipe外键约束，您可能还是想使用InnoDB。

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

• 您必须始终使用应用程序开发人员select的引擎
• 如果他们没有select特定的引擎，他们对于使用MySQL并不是很认真，可能不知道如何正确使用它。
• 你不能切换到你的应用程序testing的引擎，它可能会引入错误。

我的主机提供商build议我们彻底摆脱MyISAM并切换到InnoDB，除非不可能。

在我们的情况下，我们有严重的数据损坏，每天开始显示几次到几次，总是需要REPAIR TABLE和相关的命令，这些命令花费了大量的时间。

一旦我们转换（或：转换）到InnoDB，问题立即消失。 我们有下跌/警告：

• 不能用FULLTEXT索引来转换表格（这个问题本身就会随着时间而消失;它被一个基于Solr / Lucene的解决scheme取代，而且它的质量要好得多）
• 有数百万行往往需要COUNT（*）的大表很慢，我们也无法切换这些。

但是请注意：这一切都是特定于我们的环境等，所以通常不适用。