単一の MySql セッションが与えられた場合、クエリ A がテーブルの読み取りを実行し、クエリ B がテーブルに対して書き込みを実行すると、クエリ A が返すものに影響を与えるとします。
クエリ A に続いて (おそらく数ミリ秒後) クエリ B を送信した場合、結果は確定的ですか? クエリ B がクエリ A より前に完了することは可能ですか?
または、順序が代わりに [クエリ B、クエリ A] である場合、クエリ A の結果にクエリ B で行われた変更が含まれるという保証はありますか?
単一のセッションについて話している場合は、MySQL が複数の同時クエリをサポートしていないことに注意してください。クエリ B を実行する前に、クエリ A の読み取りを終了する必要があります。
一部のクライアント インターフェースでは、クエリ B の実行に移ったとしても、クエリ A から結果を取得できるように見えます。しかし、これが可能なのは、クライアント ライブラリがクエリ A からすべての結果をアプリケーション メモリに取得済みであるためです。後続のフェッチは実際にはメモリ内の結果を反復しているだけであるため、コードに表示されます。
複数の同時セッションについて話している場合は、@ Ian Atkin の答えが役立ちます。ストレージ エンジンとトランザクション分離レベルが結果に影響を与える可能性があります。
あなたが求めているのは、採用されているテーブルの種類と、クエリが同じスレッドにあるか、複数のセッションからのものかによって、いくつかの点で決まります。これに関する完全な議論については、特に「ロック」に関するMySQL ドキュメントを参照してください。
これらのクエリが同じスクリプトによって実行されている場合、おそらく問題はありません。クエリ B は、クエリ A などの結果に影響しません。
ドキュメントから...
MySQL は、MyISAM、MEMORY、および MERGE テーブルにテーブル レベルのロックを使用し、BDB テーブルにページ レベルのロックを使用し、InnoDB テーブルに行レベルのロックを使用します。
多くの場合、どのロック タイプがアプリケーションに最適かについて知識に基づいて推測することができますが、通常、特定のロック タイプが別のロック タイプよりも優れているとは言えません。すべてはアプリケーションに依存し、アプリケーションのさまざまな部分でさまざまなロック タイプが必要になる場合があります。
行レベルのロックでストレージ エンジンを使用するかどうかを決定するには、アプリケーションの機能と、使用する select ステートメントと update ステートメントの組み合わせを確認する必要があります。たとえば、ほとんどの Web アプリケーションは、多くの選択、比較的少ない削除、主にキー値に基づく更新、およびいくつかの特定のテーブルへの挿入を実行します。ベースの MySQL MyISAM セットアップは、このために非常によく調整されています。
MySQL のテーブル ロックは、テーブル レベルのロックを使用するストレージ エンジンではデッドロックが発生しません。デッドロックの回避は、クエリの開始時に常に必要なすべてのロックを一度に要求し、常に同じ順序でテーブルをロックすることによって管理されます。