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

Question

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

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

Answer 1

尽管其他线程（MyISAM versus 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-keeping-fulltext.html

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