MyISAMではなく、原則InnoDBを使う
あまり考えずに、MyISAMを使うこと前提にSQLを書いていたのですが、やっぱりInnoDBを使おうと思ったのでメモしておきます。
各テーブルのストレージエンジンとして、MyISAMを使うか。InnoDBを使うか。
MyISAM InnoDBで検索すると、比較記事が山とひっかかるように、古くして新しい問題（みたい）です。
MySQLでは、受発注データ等のトランザクションを厳密にやる必要がある場合でなければ、トランザクションの処理をしない等によりスピードが速いから標準のMyISAMを使っておくといいよ、ぐらいに理解してました（入門者が入門レベルの記事をざっと読んだものですので^^;）
しかし最近の流れは、
原則として、InnoDB。例外的に、MyISAM
という感じのようです。
背景には、InnoDBの性能向上やMyISAMのテーブルロック等があるみたいですね。
以下の記事等が大変参考になりました。
▽MySQLチューニング（パフォーマンスチューニングblog／株式会社インターオフィス）
http://www.inter-office.co.jp/contents/category/mysql-tuning/
※上記カテゴリの記事一覧では、記事内のリンクが表示されないので、個々の記事を開いて読むことをオススメします
▽MyISAMからInnoDBへ切り替えるときの注意点（漢(オトコ)のコンピュータ道）
http://nippondanji.blogspot.com/2009/02/myisaminnodb.html
※切り替える時、となってますが、わかりやすい比較記事にもなっていますね。
更新系はInnoDB、参照系はMyISAMと言われるように、本来は特性にあわせてストレージエンジンを選択し、それにあわせて（エラー等の処理も含めて）アプリケーション側でうまく対応する。それによってMySQLの本来の力を発揮させてあげることがあるべき姿なのでしょう。
以下の記事らからはそれをとても感じます。
が、入門者くんにはすぐさまそれらに対応するのは無理(^^;なので、とりあえずInnoDBで一通り学んだ上で、MyISAMも使えるようになる。
どっちが原則か、間違えると後で苦労するので今気付いてよかったです（正しいかどうかはともかく）。
▽MySQLによるデータウェアハウス構築（Yahoo! JAPAN Tech Blog）
http://techblog.yahoo.co.jp/web/yahoo/mysql/
▽参照と更新が頻繁に発生するテーブルでMyISAMとInnoDBを比較（cloned log）
http://d.hatena.ne.jp/cloned/20090621
ついでにこちらの記事も。
うーん、「別テーブルに追い出す」か、「取り出して、関連テーブルとして抽出する」か。
DBの正規化の観点も含め、再度検討してみようと思います。
馬鹿の考え休むに似たりともいうので、とりあえず作ってノウハウがたまったところで、それにもとづいてスクラッチアンドビルドする方がよさそうな気もしますが（どうせ一人で作るサービスなんだから）。しかしせっかくの先人の知恵なのですから、しっかり学んで先に進みたいところです。
集約演算って何かと思ったらcountなのですね。知らないことばかり。
▽MySQL (InnoDB) における行のサイズと速度の関係について（kazuhoのメモ置き場）
http://d.hatena.ne.jp/kazuhooku/20080210/1202624721
▽データベースのレコードサイズ（lethevert is a programmer）
http://d.hatena.ne.jp/lethevert/20080211/p3
最後に気をつけておきたい点。知らなかったら多分ハマったと思います。ありがとうございます。
▽InnoDB と MyISAM の AUTO_INCREMENT の違い（はきだめし）
http://d.hatena.ne.jp/miruto824/20090804/1249362494
■2009/10/30追記
全部ちゃんとわかったわけじゃないのですが、後日の自分のために関連メモ
▽MyISAMとInnoDBのどちらを使うべきか（open database life）
http://opendatabaselife.blogspot.com/2009/10/myisaminnodb.html
▽(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目（kazuhoのメモ置き場）
http://d.hatena.ne.jp/kazuhooku/20091029/1256775791
