MySQL 分析 - PROCESSLIST の詳細を表示
- 黄舟オリジナル
- 2017-03-02 16:02:122350ブラウズ
前回投票システムを作成したとき、活動のピーク時に長時間停止してしまい、一時的に帯域幅を増やしても効果が分かりませんでした。
分析のためにサーバーに移動します。topのCPUがIO待機で大量に消費されます。すべての兆候は、mysql、遅いログクエリ、インデックス構造を示していますが、根本的な問題は見つかっていないように感じます。最後に、ショーで プロセスリストを確認すると、大量のロックプロセスが見つかりました。ハハ、問題は明らかです。
投票テーブルは mysiam エンジンを使用します。投票がカウントされた後、更新によりテーブルがロックされます。また、サーバーのパフォーマンスは一般に遅く、投票処理時にプログラムは非同期ではありません。ページをダウングレードすると、さまざまな要因が重なり、非常に行き詰まります。しかし、重要な要素は依然として見つかりました、それは mysql ロックでした。
したがって、mysql のパフォーマンスに問題がある場合でも、SHOW PROCESSLIST は実行中のスレッドを表示するのに非常に効果的です。たとえば、次のようになります。
その中でも、状態列の情報は非常に重要です。まず各列の意味を見てから、状態の共通ステータスを見てみましょう
kill する識別子 mysql> kill 207; などの場合に使用します。 user:
root でない場合は、これを表示します。このコマンドは、自分の権限内の SQL ステートメントのみを表示します3. ホスト: このステートメントの送信元の IP とポートを表示し、問題のあるステートメントを発行したユーザーを追跡するために使用できます
4。 db: どの
を表示します。 5. コマンド: 現在の接続で実行されたコマンドを表示します。
通常はスリープ、クエリ、接続
時間: 6.のこの状態、単位は秒です
7. 状態: は、現在の接続を使用して SQL ステートメントのステータスを表示します。これは、ステートメントの実行における特定の状態にすぎません。コピーする必要があるクエリなど。 tmpテーブルへ、結果のソート、データの送信などの状態を完了できます
8. 情報: この SQL ステートメントを表示します。長さに制限があるため、長い SQL ステートメントは完全には表示されませんが、問題のあるステートメントを判断するための重要な基礎になります
状態の共通状態分析
1. Sleep
は、通常、接続プールを介している場合、スリープ状態が特定の数値範囲内で一定であることを意味します。
データのクエリ時間は0.1秒、ネットワーク出力は約1秒かかります。元のデータ接続は0.1秒で解放できますが、フロントエンドプログラムはクローズ操作を行わずに結果を直接出力するため、ユーザーのデスクトップに結果が表示されなくなるまで、データベース接続はスリープ状態のままになります
操作はロックされており、通常は innodb を使用することで発生を減らすことができますロック状態の
インデックスと既存の構造がクエリ条件をカバーできない場合、クエリ要件を満たすために一時テーブルが作成されます。 tmp テーブルへのコピーは通常、結合テーブル クエリに関連しています。この状態のステートメントの実行時間が長すぎる場合は、関連するクエリを減らすか、クエリ ステートメントを徹底的に最適化することをお勧めします。他の操作に重大な影響を与える可能性があります
4. データの送信はデータの送信ではなく、データの取得のプロセスです。大きな影響を与える結果セットがある場合は、送信するときに別のディスク フラグメントからデータを抽出する必要があります。
データ接続が多すぎるのは、通常、特定のクエリの影響結果セットが大きすぎるためです。つまり、クエリのインデックス項目が十分に最適化されていません。 5. クエリ キャッシュへの結果の保存
。頻繁に発生する場合 この状態が発生した場合は、セット プロファイリング分析を使用します。 SQL オーバーヘッド全体の中でリソース オーバーヘッドが大きすぎる場合 (たとえオーバーヘッドが非常に小さい場合でも、比率を確認してください)、クエリを意味します。 多くのキャッシュフラグメントがあります。すぐにクリーンアップするには、クエリキャッシュパラメータを適切に設定してください
上記は、Mysql 分析-show PROCESSLIST の詳細です。 PHP 中国語 Web サイト (www .php.cn) に注意してください。