You should convert all data to InnoDB to prevent table locking issues. However, here are somethings to think about:
FULLTEXT Indexing
At present, only MyISAM supports FULLTEXT indexing. FULLTEXT indexing for InnoDB is currently in the works for MySQL 5.6 but is not production-ready. If you have any Drupal tables that have FULLTEXT indexes, they cannot be converted to InnoDB at this time.
UPDATE on FULLTEXT Indexing
MySQL 5.6 is now GA (out for Production Use). Please try out FULLTEXT indexing in InnoDB.
To locate those tables that have a FULLTEXT
index, run this query:
SELECT table_schema,table_name
FROM information_schema.statistics
WHERE index_type='FULLTEXT';
If no rows come back, convert all InnoDB tables to your heart's content. I wrote an earlier post on how to convert all MyISAM tables to InnoDB using only mysql.
MySQL Replication
If you have a read-heavy environment, reads can go faster in MyISAM if you do the following:
- Setup Master/Slave Replication
- Create one or more Read Slaves under the Master
- Add
--skip-innodb
in /etc/my.cnf on all Slaves (converts tables to MyISAM when loading data into the Slave)
- Change the row format of all MyISAM tables on every Slave to FIXED by this command:
ALTER TABLE tblname ROW_FORMAT=FIXED;
- I posted something on this in the DBA StackExchange
- The book MySQL Database Design and Tuning recommends using
ROW_FORMAT=FIXED
on pages 72,73. This will internally convert all VARCHAR fields to CHAR. It will make the MyISAM table larger, but executed SELECTs against it will be much faster. I can personally attest to this. I once had a table that was 1.9GB. I changed the format with ALTER TABLE tblname ROW_FORMAT=FIXED
. The table ended up 3.7GB. The speed of the SELECTs against it was 20-25% faster without improving or changing anything else.
The only headache with this is making your application aware of separate read slaves.
EPILOGUE
If you are looking at other benefits each storage engine has, check the DBA StackExchange: