将MyISAM转换为InnoDB。 有利？ 后果是什么？

Question

我们正在运行一个社交网站，记录每个成员的行为（包括访问其他成员的页面）; 这涉及到db的大量写入。 这些操作存储在MyISAM表中，并且由于某些东西开始对CPU征税，我首先想到的是MyISAM的表锁定会对CPU造成这种压力。

• 只有读取和写入，没有对此表的更新。 我认为这个表的读写之间的平衡大约是50/50，因此InnoDB会是更好的选择吗？
• 如果我想将表更改为InnoDB并且我们不使用外键约束，事务或全文索引 - 我是否需要担心什么？

Answer 1

尽管在其他线程（ MyISAM与InnoDB ）中讨论了其使用的任何优点/缺点，但迁移是一个非常重要的过程。

考虑

• 在可能的情况下，功能性地测试与数据库通信的所有组件 - 差异引擎具有不同的语义
• 尽可能多地运行性能测试 - 有些事情可能会改善，有些可能会更糟糕。 一个众所周知的例子是大表上的SELECT COUNT（*）。
• 检查所有代码是否会优雅地处理死锁 - 您可以在不明确使用事务的情况下获取它们
• 估算转换所需的空间使用量 - 在非生产环境中测试。

毫无疑问，您需要在大型软件平台中进行更改; 这没关系，但看到你（希望）有很多自动测试覆盖率，改变应该是可以接受的。

PS：如果“某事开始对CPU征税”，那么你应该a）在非生产环境中找出什么，b）在非生产环境中尝试各种选项来减少它。 当你没有完全分析问题时，你不应该盲目地开始做诸如更改数据库引擎之类的重大事情。

所有性能测试都应该在非生产环境中完成，具有类似生产的数据和生产级硬件。 否则很难正确解释结果。

Answer 2

关于其他潜在的迁移问题：

1）空间 - InnoDB表通常需要更多的磁盘空间，尽管新版InnoDB的Barracuda文件格式缩小了差异。 您可以通过转换表的最近备份并比较大小来了解这一点。 使用“show table status”比较数据长度。

2）全文搜索 - 仅限MyISAM

3）GIS / Spatial数据类型 - 仅在MyISAM上

在性能方面，正如其他答案和参考答案所示，这取决于您的工作量。 对于全表扫描，MyISAM快得多。 对于高度并发访问，InnoDB往往要快得多。 如果您的查找基于主键，InnoDB也可以更快。

另一个性能问题是MyISAM可以始终保持行数，因为它只进行表级锁定。 因此，如果您经常尝试获取非常大的表的行数，那么使用InnoDB可能会慢得多。 如果您需要解决方法，请搜索互联网，因为我已经看过几个建议。

根据表的大小，您可能还需要更新MySQL配置文件。 至少，您可能希望将字节从key_buffer转移到innodb_buffer_pool_size。 如果您将数据库保留为针对MyISAM进行优化，则无法获得公平的比较。 阅读所有innodb_ *配置属性。

Answer 3

我认为切换到InnoDB很可能会提高性能，但根据我的经验，在尝试之前你无法确定。 如果我是你，我会在同一台服务器上建立一个测试环境，转换为InnoDB并运行基准测试。

Answer 4

根据我的经验，MyISAM表仅适用于文本索引，在大文本搜索中需要良好的性能，但您仍然不需要像Solr或ElasticSearch这样的完整搜索引擎。

如果你想切换到InnoDB，但想继续在MyISAM表中索引你的文本，我建议你看看这个： http ： //blog.lavoie.sl/2013/05/converting-myisam-to-innodb-保持-fulltext.html

另外：InnoDB使用Percona的innobackupex支持实时原子备份。 在处理生产服务器时，这是天才。