☰

如何选择 MySQL 数据库引擎

tag-icon • tag-icon mysql innodb myisam
如何选择 MySQL 数据库引擎

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

是否总是要尝试两种方法并进行测量？或者是否存在关于读取与写入的数量和频率以及其他类似措施的经验法则？表的大小对典型选择有影响吗？

答案1

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

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

然而，参加上周的 MySQLConf/Percona Performance Conf 后，MySQL 领域取得了非常令人鼓舞的进展。

一些替代的存储引擎：

  1. XtraDB (InnoDB 的分支)
  2. InnoDB插件
  3. PBXT
  4. 托库数据库

此外，Percona、Google 等公司也提供了一些补丁，这些补丁对 InnoDB 性能有很大帮助。就我个人而言，我运行的是 OurDelta 版本。它对我来说运行良好，我鼓励大家查看 OurDelta 和 Percona 版本。

答案2

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

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

答案3

针对不同的 MySQL 数据库引擎，有很多基准测试。有一个不错的测试比较了 MyISAM、InnoDB 和 Falcon。Percona MySQL 性能博客， 看这里。

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

答案4

我的托管服务提供商建议我们完全摆脱 MyISAM 并切换到 InnoDB，除非这是不可能的。

在我们的案例中，我们遇到了严重的数据损坏，这种损坏开始出现几次到每天几次，总是需要修复表和相关命令，这在大型表上需要很长时间。

一旦我们转换（或：被转换）到 InnoDB，问题立即消失。我们的缺点/注意事项：

  • 无法转换具有 FULLTEXT 索引的表（这个问题随着时间的推移而自行消失；它被基于 Solr/Lucene 的解决方案所取代，该解决方案的质量要好得多）
  • 包含数百万行数据（通常需要 COUNT(*)）的大表非常很慢，我们也无法切换它们。

但请注意：这一切都特定于我们的环境等，因此可能并不普遍适用。

相关内容