私はかなり長い間正常に実行されているアプリケーションを持っていますが、最近、いくつかの項目が遅いクエリログにポップアップし始めました。すべてのクエリは複雑で、リファクタリングを使用する可能性のある醜いマルチ結合selectステートメントです。それらはすべてブロブを持っていると思います。つまり、ディスクに書き込まれます。私が興味を持ったのは、それらのいくつかにロック時間が関連付けられている理由です。どのクエリにも、アプリケーションによって設定された特定のロックプロトコルはありません。私の知る限り、明示的に指定されていない限り、デフォルトではロックに対して読み取ることができます。
だから私の質問：どのシナリオがselectステートメントにロックを待たなければならない（そしてそれによって遅いクエリログに報告される）のでしょうか？INNODB環境とMYISAM環境の両方を想定します。
ディスクの相互作用は、ある種のロック時間としてリストされますか？はいの場合、これを説明しているドキュメントはありますか？
前もって感謝します。
MyISAM は並行性の問題を引き起こします。挿入が進行中の場合、テーブル全体が完全にロックされます。
InnoDB は、MVCC が原因で書き込み/トランザクションが進行中であっても、読み取りに問題はないはずです。
ただし、低速クエリ ログにクエリが表示されているからといって、クエリが低速であるとは限りません。何秒、何レコードが調べられているのでしょうか?
クエリの前に「EXPLAIN」を付けて、クエリで行われている検査の内訳を取得します。
EXPLAIN について学習するための優れたリソースは次のとおりです (それに関する優れた MySQL ドキュメント以外)。
MySqlについてはよくわかりませんが、SQLServerではselectステートメントがロックに対して読み取られないことは知っています。そうすることで、コミットされていないデータを読み取ることができ、重複したレコードが表示されたり、レコードが完全に失われたりする可能性があります。これは、別のプロセスがテーブルに書き込んでいる場合、データベースエンジンが、一部のデータを再編成してディスク上でシフトする時期であると判断する可能性があるためです。つまり、すでに読んだレコードを最後まで移動して再度表示するか、最後から1つ上に移動して、すでに過去のレコードを表示します。
ネット上のどこかに、これが発生することを証明するために実際にいくつかのスクリプトを書いた人がいます。私はそれらを1回試しましたが、重複が表示されるまでに数秒しかかかりませんでした。もちろん、彼はそれが起こりやすくなるような方法でスクリプトを設計しましたが、それは間違いなく起こり得ることを証明しています。
データが正確である必要がなく、デッドロックを確実に防ぐのに役立つ場合、これは問題のない動作です。ただし、人のお金のようなものを扱うアプリケーションで作業している場合、それは非常に悪いことです。
SQL Serverでは、WITH NOLOCKヒントを使用して、selectステートメントにロックを無視するように指示できます。MySqlで同等のものが何であるかはわかりませんが、おそらくここにいる他の誰かが言うでしょう。