我们正在运行一个社交网站,记录每个成员的行为(包括访问其他成员的页面);这涉及到数据库的大量写入。这些操作存储在 MyISAM 表中,由于某些事情开始对 CPU 造成负担,我的第一个想法是 MyISAM 的表锁定导致了 CPU 的这种压力。
- 只有读取和写入,此表没有更新。我认为该表的读写平衡约为 50/50,因此 InnoDB 会是更好的选择吗?
- 如果我想将表更改为 InnoDB 并且我们不使用外键约束、事务或全文索引 - 我需要担心什么吗?
尽管在其他线程( MyISAM 与 InnoDB )中讨论了其使用的任何优点/缺点,但迁移是一个不平凡的过程。
考虑
毫无疑问,您将需要在大型软件平台中进行更改;这没关系,但是看到您(希望)有很多自动测试覆盖率,更改应该是可以接受的。
PS:如果“某事开始对 CPU 征税”,那么您应该 a)在非生产环境中找出什么,b)在非生产环境中尝试各种选项来减少它。当您没有完全分析问题时,您不应该盲目地开始做诸如更改数据库引擎之类的主要事情。
所有性能测试都应在非生产环境中使用类似生产的数据和生产级硬件进行。否则很难正确解释结果。
关于其他潜在的迁移问题:
1) 空间 - InnoDB 表通常需要更多磁盘空间,尽管新版本 InnoDB 的梭子鱼文件格式缩小了差异。您可以通过转换表的最近备份并比较大小来了解这一点。使用“显示表状态”来比较数据长度。
2) 全文搜索 - 仅在 MyISAM 上
3) GIS/空间数据类型 - 仅在 MyISAM
在性能方面,正如其他答案和参考答案所示,这取决于您的工作量。MyISAM 对于全表扫描要快得多。对于高并发访问,InnoDB 往往要快得多。如果您的查找基于主键,InnoDB 也可以更快。
另一个性能问题是 MyISAM 可以始终保持行数,因为它只进行表级锁定。因此,如果您经常尝试获取一个非常大的表的行数,那么使用 InnoDB 可能会慢得多。如果您需要解决此问题的方法,请在 Internet 上搜索,因为我已经看到了一些建议。
根据表的大小,您可能还需要更新 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-保持全文.html
另外:InnoDB 支持使用 Percona 的 innobackupex 进行实时原子备份。这是处理生产服务器时的天赐之物。