14

私はこれについて基本的な理解を持っていると思いますが、データベースのパフォーマンスについてもっと知りたいので、誰かが私に詳細を教えてくれることを願っています.

何百万ものエントリを持つ非常に大きなデータベースがあり、データベースは多くの接続をサポートしているとしましょう。非常に多くのデータがあるため、データベースで単純なクエリを実行すると遅くなります。特定の接続でのクエリが、他の接続で実行されているクエリのパフォーマンスに直接影響を与え始める時期を正確に理解しようとしています。

1 つの接続がいくつかの要素をロックすると、それらの要素を必要とする他の接続を実行しているクエリが停止することを理解しています。たとえば、次のようにします。

SELECT FOR UPDATE

選択しているものをロックします。

次のような単純なことをするとどうなりますか。

SELECT COUNT(*) FROM myTable

10 億行のテーブルがあるとしましょう。そのため、カウントの実行には時間がかかります (innodb での実行)。他の接続で実行されているクエリに影響しますか?

次のように、SELECT と JOIN を使用して大量のデータを選択するとどうなりますか。

SELECT * FROM myTable1 JOIN myTable2 ON myTable1.id = myTable2.id;

ジョインロックは他のクエリに対して何かありますか?

どのクエリが他の接続で実行されているクエリのパフォーマンスに直接影響するかを知るのは難しいと感じています。

ありがとう

4

3 に答える 3

5

さまざまな角度があります。

  • 行のロック: アーキテクチャを調整する場合、これは発生しないはずなので、忘れてください。
  • 実際のパフォーマンスの問題とボトルネック。私たちの場合、付随効果。

この 2 番目の点について、問題は主に 3 つの領域に分けられます。

  • ディスク読み取り
  • メモリ使用量 (バッファ)
  • CPU使用率。

ディスクの読み取りについて: 取得するデータ (バイト単位) が多いほど、ハードドライブがビジー状態になり、それを使用する他のアクティビティが遅くなります。ディスクのオーバーヘッドを回避するために、選択した行のサイズを減らします。

メモリ使用量について: mysql は内部バッファを管理しますが、状況によってはスタックする可能性があります。私はあなたに適切な答えを与えるのに十分な知識はありませんが、これは間違いなくあなたが注目すべきものであることを知っています.

CPU 使用率について: 基本的に CPU はビジー状態になります。

  • 計算する必要があります（結合、ステートメントの準備、算術...）
  • たとえば、ディスクからメモリにバイトを移動するなど、すべての周辺処理を行う必要があります。クエリを最適化して、CPU オーバーヘッドを削減します。（ばかげているように聞こえますが、とにかく、それは常に問題であることが判明します...）

では、巻き添え効果がいつ発生するかはいつわかるのでしょうか。ハードウェアをプロファイリングすることによって... プロファイリングの方法は?

  • 絶対プロファイリング:SHOW INNODB STATUSまたはSHOW PROFILEを使用して、メインの mysql ハードドライブ、CPU、およびメモリ ウォッチに関する有用な情報を取得します。
  • 相対プロファイリング: お気に入りの OS プロファイラーを使用します。たとえば、Windows XP では、mysql プロセスの greatとperfmon.exewatch を使用できます。結局のところ、コンピューターでクエリに時間がかかる場合は、NASA システムにない可能性があるため、相対的だと言います...PRIVATE BYTESVIRTUAL BYTES

お役に立てば幸いです。

于 2012-07-01T19:35:31.047 に答える
3

これは非常に一般的な質問であるため、正確な回答を提供することは困難です。

データベースは、共有リソースのプールと考えることができます。特に、データベースを実行する基盤となるハードウェアには物理的な制限があるためです。ほとんどの場合、他のクエリのパフォーマンスに影響を与える選択クエリのようなものが表示される理由は、ディスク IO、RAM アクセス、または CPU 時間などの基礎となる物理リソースを使用するためにすべてが競合していて、回避するのに十分でないためです。 .

したがって、表示される実際の結果は、データベースの物理ハードウェアと構成設定に大きく依存します。

たとえば、select の例では、変数は次のようになります。クエリが必要とするデータは既に RAM にありますか? インデックスによって行を効率的に参照できますか? IO を実行する必要がある場合、ディスクからのデータの読み取りを要求しているクエリは他にいくつありますか? セカンダリ インデックスを使用していて、複数の読み取りを行う必要がありますか? データベースは他のページをバッファリングするために先読みを行っていますか? クエリがシーケンシャルまたはランダム io を引き起こしているか? データのロックを保持している更新はありますか? 物理ハードウェアがサポートできる読み取り IO の量は?

他のクエリのパフォーマンスに影響を与えるかどうかを知るには、現在実行中のすべてのクエリについてこれらすべての質問に答える必要があります。

これが DBA が存在する理由です。ビジーなデータベースは複雑なシステムであり、非常に多くの異なる操作の相互作用がすべてであり、すべてに影響を与える可能性のある数千の変数があります。

したがって、一般的に行うことは、制御できるものと方法を知っているもの (ハードウェア、mysql 構成、スキーマ、およびインデックス) を最適化し、実行中のシステムを測定して実際に何が起こっているかを理解することです。

したがって、あなたの場合、クエリを個別に最適化することに集中する方がはるかに役立つと言えます。実行が速ければ速いほど、おそらく使用するリソースが少なくなり、他の人に影響を与える変更も少なくなります。次に、システムを分析する方法を学びます。遅いものを 1 つ見て、「なぜこれが遅いのか」と尋ねてみてください。次に、それを修正します。それが最適化プロセスです。

ただし、SELECT ... FOR UPDATE で記述した最初のケ​​ースでは、明示的なロックが大きなパフォーマンスの問題になる可能性があります。それらに注意してください。

于 2012-07-01T19:46:59.353 に答える
3

読み取りクエリは、他のクエリの分離レベルによってのみ影響を受けます。それら自体がテーブルをブロックすることはありません。

分離レベルは、指定されたトランザクションの安全モードです。ロックを使用する別のクエリがダーティ リードを許可しない場合、他のクエリが書き込みを終了するかロックを解除するまで、読み取りは保持されます。

MVCCは、データベースが更新または削除する必要があるときに、データベースが新しいバージョンのデータを作成できるようにするメカニズムです。つまり、現在のバージョンのデータで読み取りを開始すると、そのデータは将来の更新/削除によって汚染されません。

データが現在別のプロセスによって読み取られているにもかかわらず、現在のデータの書き込みを開始すると、実際には新しいものを別の場所に書き込み、それらを最新バージョンとしてマークしています。最終的には、書き込みプロセスがブロックされないことを意味します（少なくとも読み取りプロセスが原因ではありません）。

于 2012-07-01T19:35:08.507 に答える