Question

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.

• There are only reads and writes, no updates to this table. I think the balance between reads and writes is about 50/50 for this table, would InnoDB therefore be a better option?
• If I want to change the table to InnoDB and we don’t use foreign key constraints, transactions or fulltext indexes – do I need to worry about anything?

Answer 1

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

Consider

• Functionally testing all components which talk to the database if possible – difference engines have different semantics
• Running as much performance testing as you can – some things may improve, others may be much worse. A well-known example is SELECT COUNT(*) on a large table.
• Checking that all your code will handle deadlocks gracefully – you can get them without explicit use of transactions
• Estimate how much space usage you’ll get by converting – test this in a non-production environment.

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: 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.