关于mysql:将MyISAM转换为InnoDB。 有利?后果是什么?

Converting MyISAM to InnoDB. Beneficial? Consequences?

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

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


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

考虑

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

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

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

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


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

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_ *配置属性。


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


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

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

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