mysqlの実行プロセスの分析

MySQL は、サーバー層とストレージ エンジン層の 2 つの部分に分割できます。

サーバー層には、コネクタとストレージ エンジン層が含まれます。クエリ キャッシュ、アナライザー、オプティマイザー、エグゼキューターなど、MySQL のコア サービス関数とすべての組み込み関数のほとんどをカバーします。すべてのクロスストレージ エンジン関数 (ストアド プロシージャ、トリガー、ビューなど) はこの層に実装されます。

ストレージ エンジン層は、データの保存と取得を担当します。そのアーキテクチャ モデルはプラグインであり、InnoDB、MyISAM、Memory などの複数のストレージ エンジンをサポートします。現在最も一般的に使用されているストレージ エンジンは InnoDB

(無料学習ビデオ チュートリアルの推奨事項:

mysql ビデオ チュートリアル)

SQL 実行プロセスを見てみましょう

コネクタ

最初のステップでは、最初にデータベースに接続します。この時点でコネクタが受信します。コネクタは、クライアントとの接続の確立、権限の取得、接続の維持と管理を担当します。

接続が完了した後、その後何もアクションを行わない場合、接続はアイドル状態になります。

クライアントが長時間非アクティブな場合、コネクタは自動的にクライアントを切断します。この時間はパラメータ wait_timeout によって制御されます。デフォルト値は 8 時間です。

接続を確立するプロセスは通常複雑であるため、使用中は接続を確立するアクションを最小限に抑える必要があります。長い接続を使用する

ただし、長い接続をすべて使用した後、MySQL が占有するメモリが急速に増加することがあります。これは、MySQL が実行中に一時的に使用するメモリが接続オブジェクトで管理されるためです。これらのリソースは、接続が切断された場合にのみ解放されます

この問題を解決するには? 次の 2 つのオプションを検討できます。

1. 長い接続を定期的に切断します。一定期間使用した後、またはメモリを消費する大規模なクエリが実行されたとプログラムが判断した後、接続は切断され、クエリが必要になってから再接続されます。

2. MySQL 5.7 以降を使用している場合は、比較的大規模な操作を実行した後、毎回 mysql_reset_connection を実行することで接続リソースを再初期化できます。このプロセスでは再接続や権限の確認は必要ありませんが、接続が確立された後、接続は作成されたばかりの状態に復元されます。

クエリ キャッシュ

select ステートメントを実行できます。実行ロジックは 2 番目のステップであるクエリ キャッシュに進みます。 MySQL はクエリ リクエストを取得すると、まずクエリ キャッシュに移動して、このステートメントが以前に実行されたかどうかを確認します。以前に実行されたステートメントとその結果は、キーと値のペアの形式でメモリに直接キャッシュされる場合があります。キーはクエリ ステートメントであり、値はクエリの結果です。クエリがこのキャッシュ内でキーを直接見つけることができた場合、値はクライアントに直接返されます。

ステートメントがクエリ キャッシュにない場合は、後続の実行ステージが続行されます。実行が完了すると、実行結果はクエリ キャッシュに保存されます。クエリがキャッシュにヒットした場合、MySQL は後続の複雑な操作を実行せずに結果を直接返すことができることがわかります。この効率は非常に高くなります。

しかし、ほとんどの場合、クエリ キャッシュは使用されません。なぜですか? なぜなら?クエリ キャッシュは、多くの場合、利益よりも害の方が大きくなります。

クエリ キャッシュは非常に頻繁に失敗します。テーブルが更新されている限り、このテーブル上のすべてのクエリ キャッシュはクリアされます。そのため、せっかく結果を保存したのに、使用する前にアップデートによって消えてしまったという可能性もあります。更新圧力が高いデータベースの場合、クエリ キャッシュのヒット率は非常に低くなります。ビジネスに長期間のみ更新される静的テーブルがある場合を除き、

パラメータ query_cache_type を DEMAND に設定して、クエリ キャッシュがデフォルトの SQL ステートメントに使用されないようにすることができます

MySQL バージョン 8.0 では、クエリ キャッシュ関数全体が直接削除されます。つまり、この関数は 8.0 から完全に削除されます。

Analyzer

ヒットしない場合、ステートメントの実際の実行が開始されます。まず第一に、MySQL はユーザーが何をしたいのかを知る必要があるため、SQL ステートメントを解析する必要があります。

アナライザーは最初に「字句解析」を行います。入力したものは、複数の文字列とスペースで構成される SQL ステートメントです。MySQL は、その中の文字列が何であり、それが何を表しているのかを識別する必要があります。

これらの識別が完了したら、「構文解析」を行う必要があります。字句解析の結果に従って、構文アナライザーは、入力された SQL ステートメントが MySQL 構文を満たすかどうかを判断します。

Optimizer

アナライザーを通過すると、MySQL は何を認識しますかあなたがしたいこと。実行を開始する前に、オプティマイザによって処理する必要があります。

オプティマイザは、テーブルに複数のインデックスがある場合、またはステートメントに複数のテーブルの関連付け (結合) がある場合に、どのインデックスを使用するかを決定し、各テーブルの接続順序を決定します。

オプティマイザ フェーズが完了し、このステートメントの実行計画が決定され、次にエグゼキュータ フェーズに入ります。

executor

実行を開始するときは、まずこのテーブル T に対してクエリを実行する権限があるかどうかを判断する必要があります。権限がない場合は、権限がないというエラーが返されます。

権限がある場合は、テーブルを開いて、実行を継続します。テーブルが開かれると、エグゼキュータはエンジンによって提供されるインターフェイスを使用して、テーブルのエンジン定義に従って実行します。

この時点で、サーバー層は特定のエンジン層ロジックの実行を完了しています。次の記事で分析します

以上がmysqlの実行プロセスの分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。