Question

Consider this scenario with the following assumptions:

• The database is used for a non-critical webapp.
• Query speed is of vital importance.
• The read/write patterns are roughly >95 % reads and <5 % writes.
• The database is backuped up daily using mysqldump.
• The is no need for transactions or advanced crash recovery. If the database crashes I’ll simply import last night’s mysqldump. This is good enough in this scenario.
• No need for full-text searching.

Pros of MyISAM under said assumptions:

• It’s very fast (with one exception – see below).
• It’s light-weight and has an easy-to-understand mapping between database/table to physical files in file system (.MYD/.MYI/.frm).
• Easy backup (mysqldump).

All-in-all I’m very happy with MyISAM with one major exception. MyISAM has one major shortcoming under said assumptions and that is table level locking. When UPDATEs are running towards a frequently read table all reads are blocked. Needless to say this causes major performance problems which must be solved.

My questions are:

1. Is there some way to get rid of table level locking without switching away from MyISAM?
2. If I must switch to InnoDB – how do I configure InnoDB so that it behaves as similar to MyISAM as possible (think no transactions, logical file structure, etc.). How do I configure a InnoDB to be “just like MyISAM but without table level locking”?

Answer 1

1. No, MyISAM means table level locking.
2. You can’t get it “just like”, but you can get it “a lot more like” by turning on the innodb_file_per_table option. InnoDB will still store critical information in its system-level data file, however, and you can’t do things like casually rename a database by renaming the directory it lives in like you can with MyISAM.