3)ん?最初のdeleteが互いに「0件削除」だとデッドロック。別トランザクションのMEMBER_IDが別ID(例えば4)でもデッドロック。(とにかく両方のトランザクションでdeleteが0件であれば)これは...ネクストキーロックって?MySQLのInnoDBには「ネクストキーロック」という機構があります。詳しくは、ぐぐってくれればOKですが、ひとまず参考になるオフィシャルサイトのページを。ロック:ファントムの問題を防ぐ難しいこと書いてありますねぇ。一人しかそのデータを読めないという感じになります。Read」をサポートしていないDBもある。Read)」を防ぎます。一度読んだデータが途中で別のトランザクションに更新されても、再度読み込んだときにはその前に読んだデータが取得されます。Read)」は防ぎません。ちなみに、ファジー防止のために共有ロックが長めに保持されます。共有ロックがかかっているレコードに対する更新処理は待たされます。Committed」ですね。別にファジーもファントムも業務的にわりと許容できるしと。Read」は、ちょっと実装方法に工夫(!?)を入れることで、ファントム・リードを防いでいます。Read」ということで、長めの共有ロックによる待ちが発生しません。トランザクション継続中の検索レコードを他のトランザクションが待たずに更新できます。トランザクション継続中の検索にヒットするレコードが登録されても、再度同じ検索を何度してもヒットしません。Read」と言いつつファントム・リードを防がないのは、変だなぁという思いもあるので一理あるのかなと。不思議な動きをする部分があります。登録しようとすると、待たされます。更新ロックが登録をブロック!オフィシャルサイトの説明は、恐らくこのことを言っているのかと。ロックによって、テーブル内に存在しない物を「ロック」する事ができます。わからないけど、とにかくすごいのか恐ろしいのかわからない...でも、もうちょい怖がれます。更新ロック取得時のロック範囲について、すごく丁寧に検証されている方の記事があります。おさらいhttp://d.hatena.ne.jp/sh2/20090112すごい...とりあえず言えることは、ユニークなキーに対する条件において、指定した条件値の「次」のレコードもロックするようですね。ロックがかかってしまうと。