MySQL CPU 100%高レベルのソリューション

クズども · 掲載地 2018/10/11 11:20:31

サーバーのタスクマネージャーを開くと、CPUプロセスは常に99%で、その表示はmysqlプロセスに占有されており、これは高い数値でした。

processlistコマンドの出力はどのスレッドが実行中かを示し、データベースの現在の実行状況を確認できます。

1. mysql/binディレクトリに行き、mysqladmin processlistを入力します。
2. mySQLを起動し、show processlistを入力します。
SUPER権限があればすべてのスレッドを見ることができますが、そうでなければアカウントのスレッドのみが見えます。

各列の意味と目的

id: 識別子
user: は現在のユーザーを表示します。rootでなければ、このコマンドはあなたの権限内のSQL文のみを表示します。
host: この文がどのポートから来ているかを示す
db: プロセスが現在接続されているデータベースを表示します。
command: 現在の接続で実行されているコマンド(通常はスリープ、クエリ、接続)を表示します。
時間:この状態が続く時間(秒単位)。
状態:現在の接続を使用しているSQL文の状態を表示しますが、文の実行中にクエリされたのは特定の状態のみです。例えば、tmpテーブルへのコピー、結果のソート、データの送信などを経る必要があります
情報:このSQL文を表示します。長さに制限があるため長いSQL文は完全に表示されませんが、問題文を判断する重要な基礎となります。

最も時間がかかり、1000秒以上実行されていないSQLクエリ文が2つあり、情報フィールドからコピーしたSQL文は共同クエリであり、以下の通りです。

キャスト(count(*) as signed col_0_0_)を「RatedPassenger」ratedpasse0_、「BaseInfoCompany」baseinfoco1_、「OrderMatch」ordermatch2_baseinfoco1_から選択してください。 CompanyId=ratedpasse0_。 CompanyIDとordermatch2_。 OrderId=ratedpasse0_。 OrderId

これら2つのクエリ文のプロセスを終了します

ログインが見えます。

10秒待ったところ、CPUはかなり下がっていましたが、それでも非常に高かったので、理由を引き続き問い合わせます!

ジョインのjoint query文では、関連するフィールドにインデックスを追加するか、プログラムクエリコードを修正してください。
インデックスSQL文を作成する

ログインが見えます。

終わり

クズども · 掲載地 2018/10/11 13:03:02

このコマンドの中で最も重要なのはstate列であり、mysqlに記載されている状態は主に以下の通りです。

チェックテーブル
  データシートの確認(これは自動です)。
  クロージングテーブル
  テーブルで修正されたデータはディスクにフラッシュされ、使い切られたテーブルは閉じられます。これは簡単な操作なので、そうでなければディスク容量が満杯か、負荷がかかっているかを確認してください。
  コネクトアウト
  レプリケーションスレーブサーバーはプライマリサーバーに接続しています。
  ディスク上のtmpテーブルへのコピー
  一時結果セットがtmp_table_sizeより大きいため、一時テーブルはメモリ内からディスクストレージに変換され、メモリを保存します。
  tmpテーブルの作成
  クエリ結果の一部を保持するための一時テーブルが作成されています。
  メインテーブルからの削除
  サーバーはマルチテーブル削除の最初の部分を実行しており、最初のテーブルを削除したばかりです。
  参照テーブルからの削除
  サーバーはマルチテーブル削除の第二段階、すなわち他のテーブルからレコードを削除する作業を行っています。
  フラッシュテーブル
  FLUSH TABLESを実行し、他のスレッドがdatatableを閉じるのを待っています。
  殺害
  キルリクエストがスレッドに送られると、スレッドはキルフラグを確認し、次のキルリクエストを放棄します。 MySQLは各メインループでキルフラグをチェックしますが、場合によってはスレッドが短時間停止することもあります。スレッドが他のスレッドにロックされた場合、ロック解除と同時にキル要求が即座に有効になります。
  ロックされた
  他のクエリでロックされています。
  データの送信
  SELECTクエリのレコードは、結果がクライアントに送信される間に処理されています。
  グループごとにソートする
  GROUP BYのソート中。
  順番のソート
  ORDER BYのソートが行われています。
  オープニングテーブル
  このプロセスは、他の要因に妨げられない限り迅速に進むべきです。例えば、データテーブルはALTER TABLEまたはLOCK TABLE文が実行されるまで、他のスレッドによって開くことはできません。テーブルを開けようとしている。
  重複の除去
  SELECT DISTINCTクエリが実行されていますが、MySQLは前の段階で重複レコードを最適化できません。したがって、MySQLは結果をクライアントに送信する前に、重複レコードを再度削除する必要があります。
  再開テーブル
  テーブルのロックは取得されますが、テーブル構造が変更された後にロックを修正しなければなりません。すでにロックを解除し、データシートを閉じ、データテーブルを再開しようとしています。
  ソーティングによる修理
  修正命令は索引を作成するためのソートです。
  キーキャッシュによる修復
  修正指示は、インデックスキャッシュを使って新しいインデックスを一つずつ作成することです。ソートによる修復よりも遅くなります。
  更新のための行検索
  対象となる記録は更新のために特定されています。 UPDATEが関連レコードを修正する前に行う必要があります。
  眠っている
  クライアントからの新しいリクエストを待っています。
  システムロック
  外部システムロックの取得を待っています。同じテーブルを同時に要求するmysqldサーバーがいない場合、–skip-external-lockingパラメータを追加することで外部システムロックを禁止できます。
  ロックのアップグレード
  INSERT DELAYEDはロックテーブルに新しいレコードを挿入しようとしています。
  更新
  一致するレコードを探して修正する。
  ユーザーロック
  GET_LOCK()を待っています。
  テーブルを待つ
  スレッドにはデータシート構造が変更され、新しい構造を得るために再開が必要であることが通知されました。その後、データテーブルを再開するには、他のスレッドがすべてテーブルを閉じるまで待つ必要があります。この通知は以下のケースで発生します:FLUSH TABLES tbl_name、ALTER TABLE、RENAME TABLE、REPAIR TABLE、ANALYZE TABLE、OPTIMIZE TABLE です。
  ハンドラー挿入待ち
  INSERT DELAYEDはすべての保留中の挿入を処理し、新しいリクエストを待っています。
  ほとんどの状態は高速操作に対応しており、スレッドが数秒間同じ状態にとどまる限り、問題を確認する必要がある可能性があります。

クズども · 掲載地 2019/03/01 10:26:49

公式ドキュメントリンク:https://dev.mysql.com/doc/refman/5.7/en/show-processlist.html

クズども · 掲載地 2019/03/01 10:34:13

ログインが見えます。

データのクエリには10秒かかります。

[出典] MySQL CPU 100%高レベルのソリューション

関連記事

閲覧したセクション