Usually you want to default to InnoDB unless you know for sure that the table's usage pattern fits MyISAM's strengths. Those include read-only tables, read-infrequently tables (like configuration data), and logging tables, where you're appending a bunch of rows at once and rarely (if ever) need to mutate existing data.
If you want full-text search, you're usually better off with something like Solr/Lucene or Google Custom Search Engines than MyISAM's built-in full text indexing.
The problem with MyISAM is that if you ever get significant write-load, the table-level locking will kill you. InnoDB uses row-level locking, which scales much better under heavy writes. Writes are far more likely to be a bottleneck than reads, so the faster read speed of MyISAM is rarely a boon in practice.
Comments
Usually you want to default to InnoDB unless you know for sure that the table's usage pattern fits MyISAM's strengths. Those include read-only tables, read-infrequently tables (like configuration data), and logging tables, where you're appending a bunch of rows at once and rarely (if ever) need to mutate existing data.
If you want full-text search, you're usually better off with something like Solr/Lucene or Google Custom Search Engines than MyISAM's built-in full text indexing.
The problem with MyISAM is that if you ever get significant write-load, the table-level locking will kill you. InnoDB uses row-level locking, which scales much better under heavy writes. Writes are far more likely to be a bottleneck than reads, so the faster read speed of MyISAM is rarely a boon in practice.