InnoDB and MyISAM each have their strengths and weaknesses.
If you have enough RAM, I would choose InnoDB because it caches data and index pages in the Buffer Pool. MyISAM only caches index pages in the Key Cache.
MyISAM tables experience full table locks for each INSERT, UPDATE, and DELETE. MyISAM tables always require disk access for data.
InnoDB tables always incur disk I/O in the following areas:
- Double Write Buffer : Changes are posted in ibdata1 to avoid OS caching
- Insert Buffer : Changes to Secondary (non-Unique) Indexes as posted in ibdata1
- Data and Indexes
- With innodb_file_per_table = 0, changes are written to ibdata1
- With innodb_file_per_table = 1, changes are written to
.ibd
tablespace file. Read I/O against ibdata1 still necessary to crosscheck table metadata
SUMMARY
In an environment with the following:
- heavy writes
- heavy reads
- tons of RAM
- heavy connections
I would always choose InnoDB. Please check out my other post about InnoDB over MyISAM : When to switch from MyISAM to InnoDB?
When would I every choose MyISAM?
Under the following scenario
- Using MySQL Replication
- Master with all InnoDB
- Slave with all tables converted to MyISAM
ALTER TABLE ... ROW_FORMAT=Fixed
for all tables on the Slave
Disk I/O wise, MyISAM has a slight edge with ROW_FORMAT-Fixed
because you only interact with one file, the .MYD
file. The row size is completely predictable because VARCHAR is treated as CHAR this shortening access time for data retrieval.
On the other hand, InnoDB has to interact with multiple files (ibdata1, serveral read/write threads upon the .ibd of the InnoDB table).
Best Answer
First major difference I see is that InnoDB implements row-level lock while MyISAM can do only a table-level lock. You will find better crash recovery in InnoDB. However, it doesn't have
FULLTEXT
search indexes until v5.6, as does MyISAM. InnoDB also implements transactions, foreign keys and relationship constraints while MyISAM does not.The list can go a bit further. Yet, they both have their unique advantages in their favor and disadvantages against each other. Each of them is more suitable in some scenarios than the other.
So to summarize (TL;DR):
FULLTEXT
search indexes, InnoDB did not until MySQL 5.6 (Feb 2013).