MySQLスレッドステータスの詳細説明
#記事ディレクトリ
- 1. show processlist
- 2. コマンド コマンドの種類
- 3. ユーザー スレッドのステータス
- 4. ダンプ スレッドのステータス
- 5. IO スレッドのステータス
- 6. SQL スレッドのステータス
- 7. マスター/スレーブ接続スレッドのステータス
- 8. イベント スケジューリング スレッドのステータス
Id: 接続プロセス識別子。 CONNECTION_ID() 関数によって返される値です。
- User: ステートメントを実行した MySQL ユーザーの名前。 「システム ユーザー」が表示される場合、内部タスクを実行する MySQL によって生成された非クライアント スレッドを指します。たとえば、プライマリ/スタンバイ レプリケーションのスレーブ ライブラリで使用される I/O または SQL スレッド、または遅延行ハンドラーのスレッドです。 「未認証ユーザー」とは、クライアントがサーバーとの TCP/IP 接続を確立しているが、クライアントのユーザー パスワードをまだ認証していないスレッドを指します。 「event_scheduler」は、スケジュールされたタスクのスケジュール イベントを監視するスレッドを指します。
-
Host: ステートメントを実行しているクライアントのホスト名。host_name:client_port で表示されます (skip_name_resolve パラメーターが有効な場合は、ip:client_port 形式で表示されます) - Db: デフォルトクライアントが接続するデータベース (接続時にライブラリ名を指定した場合)、それ以外の場合は NULL として表示されます。
- Command: スレッドによって実行されているコマンドのタイプ。
- Time: スレッドが現在の状態にあった時間 (秒単位)。スレーブ SQL スレッドの場合、この値は、最後のレプリケーション イベントの時刻とスレーブの実際の時刻の間の秒数です。
- State: スレッドが実行している操作、イベント、または状態の種類をプロンプトします。
- 情報: スレッドによって実行されているステートメント。
バイナリ ダンプ: メイン ライブラリ スレッドは、バイナリ ログの内容をスレーブ ライブラリに送信するために使用されます
- Change user: スレッドはユーザー変更操作を実行しています
- Close stmt: スレッドはプリコンパイルされたステートメントを閉じています
- Connect: スレーブ スレッドはメイン ライブラリに接続されました
- Connect Out: スレーブ ライブラリがメイン ライブラリに接続中です。
- Create DB: スレッドがデータベース作成操作を実行中です。
- Daemon: これはサーバーの内部スレッドです。クライアント接続用のスレッドではありません
- Debug: スレッドはデバッグ情報を生成しています
- Delayed insert: 挿入ハンドラーを遅延させるスレッドです
- Drop DB: スレッドはデータベースの削除操作を実行しています
- 実行: スレッド プリコンパイルされたステートメントを実行しています
- フェッチ: スレッドがステートメントを実行し、そこから結果セットを取得しています
- フィールド リスト: スレッドテーブル列情報を取得しています
- Init DB: スレッドはデフォルトのデータベースを選択しています
- Kill: スレッドは他のスレッドを強制終了しています
- Long Data: スレッドはステートメントを実行していますそしてそこからロング フィールド (ラージ フィールド) タイプのデータ結果セットを取得して返します
- Ping: スレッドはサーバー ping 要求を処理しています
- Prepare: スレッドはプリコンパイルされたステートメントを実行しています
- Processlist: スレッドはサーバー スレッドに関する情報を生成しています
- Query : スレッドはクエリ ステートメントを実行中です
- Quit: スレッドは終了中です
- Refresh:スレッドはテーブル、ログ、またはキャッシュを更新しているか、ステータス変数をリセットしているか、サーバー情報をコピーしています
- スレーブの登録: スレッドはメイン ライブラリにスレーブ ライブラリを登録しています
- Reset stmt:スレッドはプリコンパイルされたステートメントをリセットしています
- Set オプション: スレッドはクライアント ステートメント実行オプションを設定またはリセットしています
- Shutdown: スレッドはサーバーをシャットダウンしています
- Sleep:スレッドは、クライアントが新しいステートメント要求を送信するのを待っています #統計: スレッドはサーバー ステータス情報を生成しています
- テーブル ダンプ: スレッドはテーブルの内容をスレーブ ライブラリに送信しています
- #3. ユーザー スレッドのステータス ##
- 作成後: この状態は、スレッドがテーブル (内部一時テーブルを含む) の作成を完了すると発生します。
この状態は、何らかのエラーによりテーブル作成がエラーになった場合でも発生します - Analyzing: Thread is ANALYZE TABLE
- checking Permissions: スレッドに実行文があるかどうかをサーバーでチェックしています Required権限
- テーブルのチェック: スレッドはテーブル チェック操作を実行しています
- クリーンアップ: スレッドはコマンドの実行を完了し、占有メモリを解放し、いくつかの状態変数をリセットする準備をしています
- テーブルを閉じています: スレッドはテーブルの変更されたデータをディスクにフラッシュし、テーブルを閉じています。
- HEAP を MyISAM に変換中: スレッドは内部一時テーブルを MEMORY エンジン テーブルからディスク MyISAM エンジン上の一時テーブルに変換しています。
- tmp テーブルにコピー: スレッドは ALTER TABLE ステートメントを実行しています。この状態は、新しい構造のテーブルが作成された後、古いテーブルのデータを新しいテーブルにコピーする前に発生します。
- グループ テーブルへのコピー: ステートメントで異なる ORDER BY 条件列と GROUP BY 条件列が使用されている場合、これらのデータ行を group by に従って並べ替え、並べ替えた結果を一時テーブルにコピーします。
- tmp テーブルにコピーしています: サーバーはデータをメモリ一時テーブルにコピーしています
- テーブルを変更しています: サーバーは-Place ALTER TABLE プロシージャで実行中
- ディスク上の tmp テーブルにコピー中: サーバーはデータをディスク上の一時テーブルにコピーしています。一時結果セットが大きすぎるため、スレッドはメモリを節約するために、メモリ内の一時テーブルをディスクベースの一時テーブルに変換しています
- インデックスの作成: スレッドは ALTER TABLE... ENABLE KEYS を実行しています。ステートメント
- ソート インデックスの作成: スレッドは SELECT を実行し、内部一時テーブルが使用されます。 #creating table: スレッドはテーブルを作成しています。このステータスは、一時テーブルを作成するときにも使用されます。
- 一時テーブルの作成: スレッドはメモリまたはディスク上に一時テーブルを作成しています。テーブルがメモリ内に作成され、後でディスク テーブルに変換された場合、操作中のステータスは「ディスク上の tmp テーブルにコピー中」になります。
- 変更テーブルをストレージ エンジンにコミットしています: サーバーは実行を完了しました。配置アルゴリズムの ALTER TABLE ステートメントは、メイン テーブルからの
- 削除を送信しています。サーバーは、複数テーブルの削除ステートメントの最初の部分を実行しています。この
- ステータスは、最初のテーブルから削除されていることを示しており、後続のテーブルの削除に使用される列データとオフセットが保存されています
参照テーブルから削除: サーバーは複数テーブルの削除を実行していますステートメントの 2 番目の部分、他のテーブルから一致する行を削除します - discard_or_import_tablespace: スレッドが ALTER TABLE ... DISCARD TABLESPACE または ALTER TABLE ... IMPORT TABLESPACE ステートメントを実行しています
- end: これはステートメント実行の終了 この状態は、ALTER TABLE、CREATE VIEW、DELETE、INSERT、SELECT、または UPDATE ステートメントをクリアする前に発生します。
- 実行中: スレッドがステートメントを実行中です。
- init_command の実行: スレッドはシステム変数を初期化するためのステートメントを実行しています
- 項目を解放しています: スレッドはコマンドの実行を完了しました。クエリ キャッシュ ステータス
- に関連するいくつかの項目をリリースします。通常、この状態の後にクリーンアップ状態が続きます。
FULLTEXT 初期化: サーバーは自然言語全文検索を実行する準備をしています。 - init: これは ALTER TABLE、DELETE、INSERT で初期化されます。 、以前に発生した SELECT または UPDATE ステートメントの状態。この状態でサーバーによって実行される操作には、バイナリ ログ、InnoDB ログの更新、および一部のクエリ キャッシュ クリーニング操作が含まれます。この状態が終了すると、次のような操作が行われる場合があります。
- テーブル内のデータが変更された後にクエリ キャッシュ エントリを削除します。
イベントをバイナリ ログに書き込みます。
blob を含むメモリ バッファを解放します。 - Killed: スレッドに対して kill 操作を開始し、スレッドは終了操作を実行する必要があります。スレッドの kill フラグは MySQL のすべてのメイン ループでチェックされますが、場合によっては、スレッドの kill に短時間しかかからない場合があります。ただし、強制終了されるスレッドが他のスレッドによってロックされている場合は、kill コマンドが有効になって実行される前に、他のスレッドがロックを解放するまで待つ必要があります。
- logging low query: スレッドはスロー クエリ ログにステートメントを書き込んでいます。
- login: クライアントが正常に認証されるまでの接続スレッドの初期状態
- manage key:サーバー テーブル インデックスの有効化または無効化
- NULL: このステータスは SHOW PROCESSLIST ステートメントに使用されます
- テーブルを開く: スレッドはテーブルを開こうとしています。テーブルを開く操作は、オープン操作がブロックされない限り、非常に高速である必要があります。たとえば、ALTER TABLE または LOCK TABLE ステートメントは、ステートメントが完了するまでテーブルが開かれないようにします。さらに、table_open_cache が十分な大きさではないため、テーブルを開けない可能性があります。
- optimizing: サーバーはクエリに対して初期最適化を実行しています
- preparing: この状態はクエリの最適化中に発生します
- 古いリレー ログのパージ: スレッドは不要なリレー ログ ファイルを削除しています
- クエリ終了: このステータスは、クエリ ステートメントの実行後、クエリ ステートメント関連のステータス項目を解放する前に発生します。
- Reading from net: サーバーはネットワークからデータ パケットを読み取っています。 MySQL 5.7.8 以降、この状態は「クライアントから受信中」と呼ばれます。 - クライアントから受信中: サーバーはクライアントからパケットを読み取っています。 MySQL 5.7.8 では、これは「ネットからの読み取り」と呼ばれます。
- 重複の削除: クエリで SELECT DISTINCT ステートメントが使用される場合、MySQL は初期段階で個別の操作を最適化できません。したがって、MySQL には、すべての重複行を削除し、その結果をクライアントに送信する追加の段階が必要です。
- removing tmp table: スレッドは、SELECT ステートメントの実行が完了した後に内部一時テーブルを削除しています。 SELECT ステートメントが一時テーブルを作成しない場合、この状態は発生しません。
- rename: スレッドは、テーブルの名前を変更するために rename ステートメントを実行しています。
- rename result table: スレッドは、テーブルの名前を変更するための ALTER TABLE ステートメント。新しいテーブルが作成され、古いテーブル名が新しいテーブルに置き換えられています。
- テーブルを再オープンします。スレッドはテーブル ロックを取得しましたが、ロックを取得した後に、基礎となるテーブル構造が変更されたことを意味します。
したがって、テーブルのロックを解放し、テーブルを閉じ、テーブルを再度開いてみます。 - 並べ替えによる修復: 修復コードは、並べ替えを使用してインデックスを作成しています。
- テーブルの変更の準備をしています。サーバーは、-place アルゴリズムの ALTER TABLE ステートメントを実行する準備をしています - 修復が完了しました: このスレッドは、MyISAM テーブルのマルチスレッド修復を完了しました
- キーキャッシュによる修復: 修復コードは、キーキャッシュを通じてキーを 1 つずつ作成する方法。これは、インデックスを並べ替えて修復する方法よりもはるかに時間がかかります。
- ロールバック: スレッドはトランザクションをロールバックしています。
- 状態の保存: MyISAM テーブル操作 (修復や分析など) の場合、スレッドは新しいテーブルをロールバックしています。ステータスは .MYI ファイルのヘッダーに保存されます。ステータスには、テーブル データ行の数、AUTO_INCREMENT カウンタ、キーなどの情報が含まれます。
distribution - 更新する行の検索: スレッドは、更新する前に一致する行をすべて検索するための最初のフェーズを実行しています。 UPDATE が関係する行の検索に使用されるインデックスを変更している場合は、まず更新に一致する行を見つける必要があります。
- データの送信: スレッドは、SELECT ステートメントによって生成されたデータ行を読み取り、処理し、送信しています。データをクライアントに送信します。この状態中に発生する操作により大量のディスク アクセス (読み取り) が発生する可能性があるため、通常、この状態は特定のクエリの有効期間内で最も長時間実行される状態です。
- クライアントへの送信: サーバーはクライアントに書き込みパケットを送信しています。 MySQL 5.7.8 より前では、これは「ネットへの書き込み」と呼ばれていました。
- setup: スレッドは ALTER TABLE 操作を実行しています
- Sorting for group: スレッドは GROUP BY ソート操作を実行しています
- 順序のソート: スレッドは ORDER BY ソート操作を実行しています。
- インデックスのソート: スレッドは、MyISAM テーブル最適化操作中により効率的なアクセスを実現するためにインデックス ページをソートしています。
- 並べ替え結果: SELECT ステートメントの場合、これは「ソート インデックスの作成」ステータスに似ていますが、非一時テーブルの場合です。
- 統計: サーバーはクエリ実行計画を最適化するために統計を計算しています。スレッドが長時間この状態にある場合、サーバーがディスク上で他の作業を実行し、統計情報の操作をブロックしているか、ロック待機が発生する可能性があります。
- システム ロック: スレッドは mysql_lock_tables() を呼び出しましたが、スレッドのステータスは更新されませんでした。これは非常に一般的な状態であり、さまざまな理由で発生する可能性があります。たとえば、スレッドはテーブルの内部または外部システム ロックを要求するか、それを待機します。これは、LOCK TABLES 中に InnoDB がテーブル レベルのロックを待機しているときに発生する可能性があります。この状態が外部ロック要求によって引き起こされた場合、同じ MyISAM テーブルへのアクセスに複数の mysqld サーバーを使用していない場合は、–skip-external-locking オプションを使用して外部システム ロックを無効にすることができます。ただし、外部ロックはデフォルトで無効になっているため、このオプションは効果がない場合があります。
SHOW PROFILE の場合、このステータスは、スレッドがロックを要求していることを示します。 - update: スレッドはテーブルの更新を開始する準備をしています
- Updating: スレッドはデータ行を検索および更新しています
- updating main table:server マルチテーブル更新ステートメントの最初の部分が実行されています。このステータスは、最初のテーブルが
更新中であり、他の (参照) テーブルの更新に使用するために列の値とオフセットが保存されていることを示します。 - 参照テーブルの更新: サーバーはマルチ テーブルの 2 番目のテーブルを実行しています。 table update ステートメント セクション、他のテーブルの一致する行を更新します。
- ユーザー ロック: スレッドは、GET_LOCK() 呼び出しを通じて要求されたロックを要求するか、提案されたロックを待機しています。 SHOW PROFILE の場合、このステータスは、スレッドが (待機せずに) ロックを要求していることを示します。
- ユーザー スリープ: スレッドが SLEEP() を呼び出して
- コミット ロックを待機中: テーブルを読み取りでフラッシュします。 LOCK ステートメントが送信ロックを取得しています
- グローバル読み取りロックを待機しています: FLUSH TABLES WITH READ LOCK グローバル読み取りロックまたはグローバル read_only システム変数設定の取得を待機しています
- テーブルを待機しています: スレッドが通知を取得します、テーブルの最下層 構造が変更されたため、新しい構造を取得するにはテーブルを再度開く必要があります。ただし、テーブルを再度開くには、他のすべてのスレッドが古いデータ構造のテーブルへのアクセスを閉じるまで待つ必要があります。この通知は、別のスレッドが FLUSH TABLES またはテーブルに対して次のステートメントのいずれかを使用した場合に発生します:
- ALTER TABLE
- RENAME TABLE * REPAIR TABLE
- ANALYZE TABLE
- OPTIMIZE TABLE
- ALTER TABLE
- RENAME TABLE
- REPAIR TABLE
- ANALYZE TABLE
- OPTIMIZE TABLE
- グローバル読み取りロックを待機しています
- スキーマ メタデータ ロックを待機しています
- ストアド ファンクション メタデータ ロックを待機しています
- ストアド プロシージャのメタデータ ロックを待機しています
- テーブル メタデータ ロックを待機しています
- トリガー メタデータ ロックを待機しています
- ネットへの書き込み: サーバーはネットワークにパケットを書き込んでいます。 MySQL 5.7.8 以降、これは「クライアントへの送信」と呼ばれます
-
マスターはすべての binlog をスレーブに送信しました; さらなる更新を待機しています: スレッドは残りのすべての binlog ファイルをバイナリログはログを更新し、スレーブライブラリに送信します。スレッドは現在アイドル状態で、新しい更新データ イベントがバイナリ ログに書き込まれるのを待っています - ビンログ イベントをスレーブに送信中: スレッドはバイナリ ログからイベントを読み取り、スレーブ ライブラリに送信します。 (バイナリ ログはイベントで構成されます。イベントは通常、更新されたデータとその他の情報で構成されます)
- 終了終了待ち: スレッドが停止したときに発生する非常に短期間の状態で、スレッドがスレッド関連のアクションを停止するために実行中です。
- #5. IO スレッドのステータス
- マスター バージョンの確認: メイン ライブラリとの接続を確立した後の非常に短い状態。メイン ライブラリのバージョン番号がチェックされていることを示します。
- マスターへの接続: スレッドは接続を試行します。メイン ライブラリへ
- マスター イベントをリレー ログにキューイング: スレッドはイベントを読み取り、SQL スレッドによる再生のためにリレー ログにコピーしました
- バイナリ ログ ダンプ要求が失敗した後に再接続します: スレッドはマスター ライブラリへの再接続を試行しています
- 失敗したマスター イベントの読み取り後の再接続: スレッドはマスター ライブラリへの再接続を試行しています。再接続が成功すると、ステータスは「マスターを待機中」に変わります。イベントを送信します。 - マスターへのスレーブの登録: メイン ライブラリへの接続に成功した後の非常に短い状態。スレーブ ライブラリの接続情報 (スレーブ ライブラリの IP やポート情報など) がマスター ライブラリに登録されていることを示します。など)
- バイナリ ダンプのリクエスト: マスター ライブラリへの接続後 ライブラリが接続を正常に確立した後の非常に短い状態で、現在の
I/O スレッド位置を使用してリクエストを送信します。現在の位置から始まるバイナリ ログの内容のメイン ライブラリ - コミットの順番を待機中:slave_preserve_commit_order パラメーターが有効な場合、
はスレーブ I/O スレッドがコミットを待機していることを示します。データを送信する古いワーカー スレッド - マスターがイベントを送信するのを待機中: スレッドはマスター ライブラリに接続されており、新しいバイナリ
ログ イベントを待機しています。これは、次の場合に長時間続く可能性があります。メインライブラリはアイドル状態です。待機がslave_net_timeout秒を超えて続く場合、スレーブI/Oスレッドはタイムアウトになります。このとき、スレーブ ライブラリの I/O スレッドは、マスター ライブラリへの接続が切断されたと考え、マスター ライブラリへの再接続を試みます。 - マスター更新待ち: マスターに接続する前の初期状態library
- 終了時のスレーブ ミューテックスの待機: スレッドの停止時に一時的に発生する状態。I/O スレッドの関連する相互排他的なリソースがリサイクルされていることを示します。
- スレーブの待機中十分なリレー ログ スペースを解放するための SQL スレッド:relay_log_space_limit 変数の設定値が 0 ではない場合、リレー ログの合計サイズがこの値を超えたとき。 I/O スレッドは、SQL スレッドがリレー ログの内容を再生し、再生されたリレー ログを削除することによって、リレー ログによって占有されている領域を解放するまで待機します。これにより、リレー ログのサイズは、relay_log_space_limit 変数の値を超えなくなります。 . 、I/O スレッドはリレー ログ操作の書き込みを続行できます。
- バイナリ ログ ダンプ リクエストが失敗した後、再接続を待機しています: バイナリ ログ ダンプ リクエストが (切断により) 失敗した場合、スレッドはスリープ状態に入ります。この状態はこの時点で発生し、その後 I/Oスレッドは定期的に再接続を試行し、メイン ライブラリに接続します。再試行の間隔は、CHANGE MASTER TO ステートメントの MASTER_CONNECT_RETRY オプションを使用して指定できます。
- スレーブ ライブラリの I/O スレッドには、接続時にハートビート メカニズムがあることに注意してください。このハートビート時間が経過しても新しいイベントがスレーブに送信されない場合、I/O スレッドはメイン ライブラリへのハートビート リクエストを開始します。リクエストが成功すると、ハートビート時間はリセットされます。メイン ライブラリがハートビート時間を送信すると、I/O スレッドはメイン ライブラリにハートビート リクエストを送信します。スレーブへの新しいイベント、このハートビート時間のリセットも発生します。ハートビート時間 change master ステートメントの MASTER_HEARTBEAT_PERIOD オプションで設定 (秒単位)、範囲は 0 ~ 4294967 秒、分解能 (ミリ秒) ゼロ以外の最小値は 0.001 で、1 ミリ秒を表します。間隔を 0 に設定すると、ハートビートが無効になります。デフォルト値は、slave_net_timeout 構成パラメータの半分です。したがって、理論的には、マスター/スレーブ データベースが正常な場合、マスター ライブラリがデータを書き込まないためにスレーブ ライブラリの I/O スレッドが切断されるという状況は発生しません。
- マスター イベントの読み取りに失敗した後、再接続を待機しています: メイン ライブラリのバイナリ ログの読み取り中にエラーが発生しました (切断のため)。 I/O スレッドがメイン ライブラリへの再接続を試行する前に、スレッドは CHANGE MASTER TO ステートメントの MASTER_CONNECT_RETRY オプション (デフォルトは 60) で設定された秒数だけスリープ状態になります (この時間は、再接続が失敗した後の再試行間隔です)。 )
- スレーブを強制終了: スレッドは STOP SLAVE ステートメントを処理しています。
- LOAD DATA INFILE を再実行する前に一時ファイルを作成 (追加): スレッドは LOAD DATA INFILE ステートメントを実行しており、次のデータを読み取ります。ライブラリを一時ファイルに追加します
- LOAD DATA INFILE を再生する前に一時ファイルを作成 (作成): スレッドは LOAD DATA INFILE ステートメントを実行し、一時ファイルを作成しています。一時ファイルには、読み取られる行データが含まれています図書館から。注: この状態は、メイン ライブラリが MySQL 5.0.3 より前のバージョンで元の LOAD DATA INFILE ステートメントを記録する場合にのみ発生します。
- リレー ログからのイベントの読み取り: スレッドはリレー ログからイベントを読み取ります。 restart
- スレーブはすべてのリレー ログを読み取りました。さらなる更新を待機しています: スレッドはすべてのリレー ログ ファイル内のすべてのイベントをやり直し、I/O スレッドがリレー ログをリレー ログに送信するのを待っています。
- コーディネーターからのイベントを待機中: スレーブ ライブラリがマルチスレッド レプリケーションを使用している場合 (slave_Parallel_workers が 1 より大きい)、このステータスは、スレーブ ワーク スレッドがコーディネーター スレッド (コーディネーター スレッド) を待機していることを示します。 ) ログを割り当てます イベント
- 終了時にスレーブ ミューテックスを待機: スレッドが停止したときに発生する非常に短い状態
- スレーブ ワーカーが保留中のイベントを解放するのを待機: 処理されたイベントの総数システム変数のサイズを超えると、待機操作が発生します (コーディネーター スレッドはイベントをワーカー スレッドに割り当てません)。ワーカー スレッドによって処理されるイベントの合計数が、slave_pending_jobs_size_max 制限を下回ると、コーディネーターはスケジューリングを再開します。この状態は、slave_Parallel_workers が 0 より大きく設定されている場合にのみ発生します。
- リレー ログの次のイベントを待機中:「リレー ログからイベントを読み取り中」状態前の初期状態
- 待機中マスターがイベントを実行してから MASTER_DELAY 秒後: SQL スレッドはイベントを読み取りましたが、適用せず、スレーブ ライブラリによって設定された遅延コピー時間が期限切れになるのを待っています。この遅延時間は、CHANGE MASTER TO
の MASTER_DELAY オプションを使用して設定されます。 ⚫ SQL スレッドの Info 列には、ステートメントのテキストを表示することもできます。これは、スレッドがリレー ログからイベントを読み取り、そこから SQL ステートメントを抽出し、現在このステートメントに対応するイベントを実行している可能性があることを意味します。 - マスターの変更: スレッドは CHANGE MASTER TO ステートメントを処理中です
- スレーブの強制終了: スレッドは STOP SLAVE ステートメントを処理しています
- マスター ダンプ テーブルを開く: この状態は、メイン ライブラリがダンプ テーブルを作成した後に発生します
- マスター ダンプ テーブル データの読み取り: 後の状態「マスター ダンプ テーブルを開いています」状態。マスター データベース ダンプ テーブルからデータが読み取られていることを示します。
- マスター ダンプ テーブルのインデックスを再構築しています。「マスター ダンプ テーブル データを読み取り中」ステータスの後に表示される状態は、次のことを示します。マスター データベース ダンプ テーブル インデックスが再構築中であること
- クリア中: スケジューラ スレッドは、イベントの実行を停止しています。イベント
- Initialized: スケジューラ スレッドが初期化されました。スケジュールされたイベントが実行されようとしています
- 次のアクティブ化を待機中: スケジューラに空でないイベント キューがある場合、スケジューラは次のアクティブ化を待機しています。スケジュールを設定して実行するために、将来のある時点でアクティブ化されるアクティブ化キュー内のイベント # スケジューラの停止を待機中: スレッドは SET GLOBALevent_scheduler = OFF を発行し、スケジューラが停止するのを待ちます
- 空のキューで待機中: スケジューラのイベント キューが空であるため、スケジューラはスリープ中です
- FLUSH TABLES tbl_name
1 つのバイナリログの読み取りを完了しました。次の binlog : スレッドは binlog ファイル
- の読み取りを終了し、次の binlog ファイルに切り替えました
6. SQL スレッドのステータス
7. マスター/スレーブ接続スレッドのステータス
8. イベント スケジューリング スレッドのステータス
関連する無料学習の推奨事項: mysql データベース(ビデオ)
以上がMySQLスレッドステータスの詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











MySQLはオープンソースのリレーショナルデータベース管理システムであり、主にデータを迅速かつ確実に保存および取得するために使用されます。その実用的な原則には、クライアントリクエスト、クエリ解像度、クエリの実行、返品結果が含まれます。使用法の例には、テーブルの作成、データの挿入とクエリ、および参加操作などの高度な機能が含まれます。一般的なエラーには、SQL構文、データ型、およびアクセス許可、および最適化の提案には、インデックスの使用、最適化されたクエリ、およびテーブルの分割が含まれます。

次の手順でphpmyadminを開くことができます。1。ウェブサイトコントロールパネルにログインします。 2。phpmyadminアイコンを見つけてクリックします。 3。MySQL資格情報を入力します。 4.「ログイン」をクリックします。

MySQLは、そのパフォーマンス、信頼性、使いやすさ、コミュニティサポートに選択されています。 1.MYSQLは、複数のデータ型と高度なクエリ操作をサポートし、効率的なデータストレージおよび検索機能を提供します。 2.クライアントサーバーアーキテクチャと複数のストレージエンジンを採用して、トランザクションとクエリの最適化をサポートします。 3.使いやすく、さまざまなオペレーティングシステムとプログラミング言語をサポートしています。 4.強力なコミュニティサポートを提供し、豊富なリソースとソリューションを提供します。

データベースとプログラミングにおけるMySQLの位置は非常に重要です。これは、さまざまなアプリケーションシナリオで広く使用されているオープンソースのリレーショナルデータベース管理システムです。 1)MySQLは、効率的なデータストレージ、組織、および検索機能を提供し、Web、モバイル、およびエンタープライズレベルのシステムをサポートします。 2)クライアントサーバーアーキテクチャを使用し、複数のストレージエンジンとインデックスの最適化をサポートします。 3)基本的な使用には、テーブルの作成とデータの挿入が含まれ、高度な使用法にはマルチテーブル結合と複雑なクエリが含まれます。 4)SQL構文エラーやパフォーマンスの問題などのよくある質問は、説明コマンドとスロークエリログを介してデバッグできます。 5)パフォーマンス最適化方法には、インデックスの合理的な使用、最適化されたクエリ、およびキャッシュの使用が含まれます。ベストプラクティスには、トランザクションと準備された星の使用が含まれます

Apacheはデータベースに接続するには、次の手順が必要です。データベースドライバーをインストールします。 web.xmlファイルを構成して、接続プールを作成します。 JDBCデータソースを作成し、接続設定を指定します。 JDBC APIを使用して、接続の取得、ステートメントの作成、バインディングパラメーター、クエリまたは更新の実行、結果の処理など、Javaコードのデータベースにアクセスします。

DockerでMySQLを起動するプロセスは、次の手順で構成されています。MySQLイメージをプルしてコンテナを作成および起動し、ルートユーザーパスワードを設定し、ポート検証接続をマップしてデータベースを作成し、ユーザーはすべての権限をデータベースに付与します。

WebアプリケーションにおけるMySQLの主な役割は、データを保存および管理することです。 1.MYSQLは、ユーザー情報、製品カタログ、トランザクションレコード、その他のデータを効率的に処理します。 2。SQLクエリを介して、開発者はデータベースから情報を抽出して動的なコンテンツを生成できます。 3.MYSQLは、クライアントサーバーモデルに基づいて機能し、許容可能なクエリ速度を確保します。

MySQLをエレガントにインストールするための鍵は、公式のMySQLリポジトリを追加することです。特定の手順は次のとおりです。MYSQLの公式GPGキーをダウンロードして、フィッシング攻撃を防ぎます。 mysqlリポジトリファイルを追加:rpm -uvh https://dev.mysql.com/get/mysql80-community-rease-el7-3.noarch.rpm update yumリポジトリキャッシュ:yumアップデートインストールmysql:yumインストールmysql-server startup mysql sportin
