菅原です。

"E-Mail" <tyunn@xxxxxxxxxx>さんは書きました：
> > 　件数が少ないならREADロックすればいいだけでは？
> > ＃場合によってはロックする必要すらないと思いますが :)
> これらはどういったケースですか？アクセス数やデータ件数が少なくても
> SELECT、INSERT、UPDATEが同時に起こるケースはまったくないという
> ことは誰にも言えないと思いますが？（誰にも公開せず一人で試験的に
> など利用することが確実なら別でしょうが）

　うーん。E-mailさんがどういうケースでの利用を想定しているのか分からない
ので（書かれてないので）なんとも言えないですけど。
　例えば、INSERTやUPDATEがcronでのみ実行される場合、同時に起こることはな
いでしょう。
　あるいは、INSERTが同時に行なわれても「先のINSERTが常に優先する」仕様な
ら、特に問題はありませんし。

＃どういうふうに設計するか、運用するかの問題ですけどね

> > （5.3.1に書かれている例は、多くのINSERTと多くのSELECTが発生したとき
> > に待ち時間を小さくするためのものですし）
> 待ち時間のことより、どのように処理が行われるかという説明と解釈しました。
> 5.3.1はそういった説明がある部分と思い読んでいます。

　いいえ、違います。
　別に別テーブルを用意しなくてもLOCK TABLESは使えますから。
　例えば更新が頻繁ではなく、１件程度なら

mysql> LOCK TABLES real_table WRITE;
mysql> insert into real_table VALUES ( foo, var, ...);
mysql> UNLOCK TABLES;

で問題ないでしょう。
　5.3.1の文章に

> 同じテーブルで多くの INSERT と多くの SELECT を行う場合、これを解決する
> には、他のテーブルに行を挿入して、たまに、その一時テーブルから全てのレ
> コードをもう一方のテーブルに update します。

とありますが、「これを解決する」の「これ」は

> これは、同じテーブルで多くの更新をする場合、SELECT 構文は update がな
> くなるまで待たされることを意味します。

に（さらに言えば「updateがなくなるまで待たされる」に）かかっていますから。

------
菅原はじめ＠ホビー・データ
sugawara@xxxxxxxxxx