将MyISAM转换为InnoDB.有利?结果? [英] Converting MyISAM to InnoDB. Beneficial? Consequences?

问题描述

我们正在运行一个社交网站，记录每个成员的行为(包括访问其他成员的页面)；这涉及到对数据库的大量写入.这些操作存储在MyISAM表中，并且由于某种事情开始对CPU造成负担，我首先想到的是MyISAM的表锁定导致CPU承受这种压力.

We're running a social networking site that logs every member's action (including visiting other member's pages); this involves a lot of writes to the db. These actions are stored in a MyISAM table and since something is starting to tax the CPU, my first thought was that it's the table locking of MyISAM that is causing this stress on the CPU.

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

推荐答案

尽管使用它有任何利弊，但其他线程对此进行了讨论(

Notwithstanding any benefits / drawbacks of its use, which are discussed in other threads ( MyISAM versus InnoDB ), migration is a nontrivial process.

考虑

• 在可能的情况下对所有与数据库通信的组件进行功能测试-不同的引擎具有不同的语义
• 尽可能多地运行性能测试-有些情况可能会改善，而另一些情况可能会更糟.一个著名的例子是在大表上的SELECT COUNT(*).
• 检查所有代码是否可以正常处理死锁-您无需显式使用事务即可获取死锁
• 估算通过转换将获得多少空间使用-在非生产环境中进行测试.

毫无疑问，您将需要在大型软件平台上进行更改；没关系，但是鉴于您(希望如此)拥有大量自动测试范围，因此更改应该可以接受.

You will doubtless need to change things in a large software platform; this is ok, but seeing as you (hopefully) have a lot of auto-test coverage, change should be acceptable.

PS:如果某种事情开始使CPU负担重"，则您应该a)在非生产环境中找出什么，b)在非生产环境中尝试各种减少它的方法.当您没有完全分析问题时，您不应盲目地开始做诸如更换数据库引擎之类的主要事情.

PS: If "Something is starting to tax the CPU", then you should a) Find out what, in a non-production environment, b) Try various options to reduce it, in a non-production environment. You should not blindly start doing major things like changing database engines when you haven't fully analysed the problem.

所有性能测试应在非生产环境中进行，并使用类似生产的数据和生产级硬件.否则很难正确解释结果.

All performance testing should be done in a non-production environment, with production-like data and on production-grade hardware. Otherwise it is difficult to interpret results correctly.

这篇关于将MyISAM转换为InnoDB.有利?结果?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！