タイトルとして、さまざまなクエリが低速クエリログに表示されます。MYSQLは "低速クエリログ"で低速クエリを実行しますが、同じクエリは手動で非常に高速に実行されます
たとえば、いくつかの順序でparamsを使った比較的簡単なselectクエリは、ログの中で最大100秒かかることがあります（テーブルは非常に大きいです）...しかし、同じDBで自分自身を実行すると2秒かかります。
私は、サーバーのパフォーマンスを検討してきたし、一度に特定の減速やボトルネックをがあるようには思えない、またその期間が、一つだけで長い時間をかけて多くのクエリです。
このような問題の分析を開始するにはどうすればよいですか？問題のクエリが遅いログに入ったときに助けを求める
おかげで
お使いのシステムは、より忙しくしている可能性があります。
slow_logは、rows_examinedが結果セットより大きい場合、インデックスが完全に利用されていないことを示します。したがって、実行時間は問合せに問題があることを示す手がかりになるはずですが、rows_examinedを使用すると決定的な回答が得られます。
負荷の高いサーバーでは、問合せ時間がパフォーマンスが低下します。これは、ビジー状態のサーバーで問合せが遅くなる可能性があるためです。 EXPLAINとSHOW PROFILEを使用してクエリをプロファイルし、サーバーに負荷をかけすぎないように改善する必要があります。
結果をクエリキャッシュに保存しないようにクエリをプロファイリングするときはSELECT SQL_NO_CACHE ...を使用します。それ以外の場合は、同じクエリの後続の実行でクエリキャッシュが使用され、クエリのタイミングがずれます。
キャッシュに関する質問：私が手動でクエリを実行したとき（同じDB上ではなくサーバー上であっても）、条件の一部を変更しましたが、結果を以前に実行されたクエリと照合することはできません。 私は説明を実行しましたが、いくつかのインデックスを使用していることを示していますが、それらが正しいかどうかは本当に分かりません。 「可能なインデックス」リストには、使用されていない他の多くのインデックスがありました。 –
また、私は、スキャンされた行の数が実際にフェッチされた行の数を大きく上回っていることに気付きました。実際には文自体はそれにLIMIT 50を持っており、スキャンした行は、周りの3000 私の考えは、それが私の理解に（クエリにLIMITがありますにもかかわらず）すべての行をfetchs文ではORDER BYによるものだということだったですそれが50を返すだけで、これは正しいのですか？ –
@MikiBergin、ORDER BY句を索引で処理できる場合は、必ずしもすべての行をフェッチする必要はありません。いくつかの警告がありますが、ここで議論するのはあまりにも多いです。特定のクエリを最適化するためのヘルプが必要な場合は、別の質問を投稿し、クエリ全体、関連するスキーマ、EXPLAINおよびSHOW PROFILEの結果を記入してください。 –
私はまず、このようなクエリの1つを「EXPLAIN SELECT ...」とともに解析して、エンジンがそのクエリ実行パスに対して何をしたいのかを表示することから始めます。 – DRapp
通常、クエリに1秒以上かかる場合は、低速クエリログに記録されます。確かに2秒は1秒以上です。 –
ワイルド推測：クエリーの最初の実行中に結果がキャッシュされたため、手動で実行するとクエリーが高速になります。これをチェックするには、すべてのキャッシュをクリアしてから同じクエリをもう一度実行してください。100秒かかるでしょう。 – nikhil500