I know this is a bit of a bump, but I fancy adding my own two cents.
InnoDB comes enabled as standard with MySQL. For it not to be there involves the host specifically disabling it (skip-innodb in the my.cnf file)
There is no major skills adjustment necessary for coping with InnoDB over MyISAM unless you’re getting to the level of doing nitty gritty performance tweaks. For the most part InnoDB will perform well out-of-the-box.
InnoDB has huge advantages over myisam, and you’ll find pretty much most major databases and software will use it. Refusal to support it would indicate a hosting company you maybe ought to be thinking twice about.
Some of the advantages of innodb:
Transactional - every transaction is logged. In the event of a crash the chances of having corrupted data in the database is much, much lower. The database runs over the transaction log contents to try to be sure everything got in safely and correctly. InnoDB is nigh on bullet proof, and MyISAM is far, far from it. It really doesn’t take all that much to corrupt a MyISAM database. Shockingly little in fact.
Personally even with low load stuff I wan the peace of mind InnoDB provides in regards to data safety.
Row Level Locking - When MySQL writes to a table, be it updating, adding or deleting rows, or whatever, it has to lock things first to ensure nothing else can write data. Given MySQL will execute queries in parallel that’s critical. MyISAM only offers table level locking. So if you’ve got two queries that come in that update completely different rows the second one has to wait for the first one to finish before it can do it’s work. InnoDB supports row level locking. In that scenario both queries could be executed simultaneously because only the row was locked for editing rather than the entire table.
Under any kind of transaction load row level locking will provide a significant performance and data consistency boost.
Backups.. well if you’re stingy enough to fret about the cost of innodb over myisam, I’m going to guess you’re “once a day” backing up types. In which case try adding this to a cron job about an hour before your file backup is due to take place:
mysqldump --opt -u <username> -p <password> magento-db-name > magento.sql
That’ll leave you a nice flat file you can re-import into MySQL easily:
mysql -u <username> -p <password> < magento.sql