MySQL のロックされたテーブルは関連するビューに影響しますか?

Question

それで読んだ後は PDO / PHP / MySQL でのパフォーマンス:トランザクションと直接実行 パフォーマンスの問題について考えていたので、MySQL でのテーブルのロックについて調べました。

の上 http://dev.mysql.com/doc/refman/5.0/en/table-locking.html

テーブルロックにより、多くのセッションが同時にテーブルから読むことができますが、セッションがテーブルに書き込みたい場合は、最初に排他的アクセスを取得する必要があります。更新中、この特定のテーブルにアクセスしたい他のすべてのセッションは、更新が完了するまで待つ必要があります。

ほとんどのクエリは挿入ではなく更新であるため、この部分は特に印象に残りました。すべての更新/挿入が実行される foo というテーブルを作成してから、すべての選択が行われる foo_view (foo のコピー、またはおそらく foo と他のいくつかのテーブルと foo のリンク) というビューを作成したのかと思っていました。このロックの問題は引き続き発生しますか?

つまり、foo_view に対する SELECT クエリは、foo での更新が完了するまで待たなければならないのでしょうか?

同僚がまた簡単な質問をしました。これはキャッシュに影響しますか?つまり、SELECT がキャッシュされている場合、キャッシュにヒットして結果を返すのでしょうか、それとも最初にロックが完了するまで待機しますか?

Answer 1

ビューでは、基になるテーブルと同じロックが発生します。

MySQL リファレンス ページより ロックする:

mysqlグラントテーブル書き込みロックは次のとおりです。

1. テーブルにロックがない場合は、テーブルに書き込みロックを設定します。
2. それ以外の場合は、ロック要求を書き込みロック キューに入れます。

mysqlグラントテーブル読み取りロックを次のように読み取ります。

1. テーブルに書き込みロックがない場合は、読み取りロックを設定します。
2. それ以外の場合は、ロック要求を読み取りロック キューに入れます。

これは使用しているデータベース エンジンによって異なることに注意してください。 マイＩＳＡＭ 上記の手順に従い、エンジンが次のような場合にテーブル全体を (複数のパーティションに分割されている場合でも) ロックします。 InnoDB 代わりに行レベルのロックを実行します。

MyISAM で必要なパフォーマンス ベンチマークに達しておらず、更新によるテーブル ロックの待機がボトルネックであることが判明した場合は、テーブルのストレージ エンジンを InnoDB に変更することをお勧めします。