将MyISAM转换为InnoDB . 有利?后果是什么?

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

  • 只有读取和写入,没有对此表的更新 . 我认为这个表的读写之间的 balancer 大约是50/50,因此InnoDB会是更好的选择吗?

  • 如果我想将表更改为InnoDB并且我们不使用外键约束,事务或全文索引 - 我是否需要担心什么?

回答(4)

2 years ago

尽管在其他主题(MyISAM versus InnoDB)中讨论了其使用的任何好处/缺点,但迁移是一个非常重要的过程 .

考虑

  • 功能测试与数据库通信的所有组件(如果可能) - 差异引擎具有不同的语义

  • 运行尽可能多的性能测试 - 有些事情可能会改善,有些可能会更糟糕 . 一个众所周知的例子是大表上的SELECT COUNT(*) .

  • 检查所有代码是否会优雅地处理死锁 - 您可以在不明确使用事务的情况下获取它们

  • 估算转换后可以获得的空间使用量 - 在非 生产环境 环境中测试 .

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

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

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

2 years ago

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

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

2 years ago

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

2 years ago

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

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

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