MySQL の全体的なアーキテクチャに関する簡単な説明

まえがき

また新しい週が始まりました、皆さん、良い月曜日をお過ごしください。

転職や家探しなどが立て続けにあったため、最近は一ヶ月以上更新が止まっていました。すべてが解決したので、安心してコーディングできます。

さて、早速、新しい旅を始めましょう。最近「MySQL Technology Insider - InnoDB Storage Engine」という本を読んでいるので、記録しておきたいと思います。

全体的なアーキテクチャ図

全体を理解するために、まず MySQL のアーキテクチャ図を見てみましょう。 MySQL は主に、ネットワーク接続層、サービス層、ストレージ エンジン層、物理層の 4 つのアーキテクチャ層に分かれています。私たちが通常作成する SQL ステートメントと SQL ステートメントの最適化はすべてサービス層にあり、実際には、SQL ステートメントが期待どおりの結果に従って実行されるように、特定の原則に従っています。

各部の紹介

ネットワーク接続層

は主に接続管理、認可認証、セキュリティなどを担当します。各クライアント接続はサーバー上のスレッドに対応します。接続ごとにスレッドが作成および破棄されるのを避けるために、サーバー上でスレッド プールを維持します。クライアントが MySQL サーバーに接続すると、サーバーはクライアントを認証します。ユーザー名とパスワードを介して認証することも、SSL 証明書を介して認証することもできます。ログイン認証後、サーバーはクライアントに特定のクエリを実行する権限があるかどうかも検証します。この層は MySQL に固有のテクノロジーではありません。

サービス層

この層は、クエリ キャッシュ、パーサー、解析ツリー、プリプロセッサ、クエリ オプティマイザーを含む MySQL の中核です。

• #クエリ キャッシュ

正式なクエリの前に、サーバーはクエリ キャッシュをチェックします。クエリの場合、クエリの解析、最適化、実行などの処理を行う必要がなく、キャッシュ内の結果セットが直接返されます。

• パーサーとプリプロセッサ

MySQL のパーサーはクエリ文に基づいて解析木を構築します。主に使用されます。 SQL キーワードが正しいかどうか、キーワードの順序が正しいかどうかなど、文法規則に基づいてステートメントが正しいかどうかを検証します。

プリプロセッサは主に、テーブル名やフィールド名が正しいかどうかなど、さらなる検証を目的としています。

• クエリ オプティマイザー

クエリ オプティマイザーは、解析ツリーをクエリ プランに変換します。一般に、クエリはさまざまな方法で実行できます。最終的には同じ結果が返されるため、オプティマイザは最適な実行計画を見つけます。

• 実行計画

分析の完了後最適化フェーズでは、MySQL は、対応する実行計画に従って、ストレージ エンジン層によって提供される対応するインターフェイスを呼び出し、結果を取得します。

ストレージ エンジン層

は、MySQL データの保存と取得を担当し、異なるエンジン間の違いを保護するための一連のインターフェイスを提供します。

注: ストレージ エンジンはテーブル用であり、ライブラリ用ではありません。つまり、同じライブラリ内の異なるテーブルは異なるストレージ エンジンを持つことができます。

一般的なストレージ エンジンには、MyISAM と InnoDB の 2 つがあります。それぞれの違いを見てみましょう。

まず、ストレージ エンジン MyISAM を使用して test1 テーブルを作成します。

create table test1( a INTEGER, b varchar(10) )ENGINE=MyISAM;

MySQL の関連ディレクトリに移動して、実際に保存されているコンテンツを確認すると、それが 3 つのファイルに対応していることがわかります。

#2 番目に、ストレージ エンジン InnoDB を使用して test2 テーブルを作成します。

create table test2( a INTEGER, b varchar(10) )ENGINE=INNODB;

実際に保存されているコンテンツを見て、それがこのファイルに対応していることを確認してみましょう。

それでは、データ ファイルとインデックス ファイルはどこに保存されているのかという疑問が生じます。質問はここで一旦残しておきます。これについては次の章「ドキュメント」で説明します。

物理層

データをハードディスクに保存します。

全体プロセス

SQL ステートメントを送信します。MySQL における全体的なプロセスはどのようなものですか?

• ユーザーはまず、Navicat などのクライアントを介してサーバーとの接続を確立します。認証にはユーザー名とパスワードが必要ですが、認証には SSL 証明書を使用することもできます。

• ログインに成功すると、MySQL は、対応する権限に基づいて、ロールに一部のテーブルに対する権限があるかどうかを判断します。

• 関連する権限がある場合、ユーザーがクエリ select ステートメントを送信すると、MySQL は最初にキャッシュにクエリを実行します。このステートメントのキャッシュが既に存在する場合は、キャッシュが直接返されます。そうでない場合は、キャッシュが直接返されます。 , 以下の処理を実行します。更新、新規挿入、または削除の場合、キャッシュは照会されず、次のプロセスが直接実行されます。

• MySQL は SQL ステートメントをツリーに解析し、キーワードが正しいかどうか、キーワードの順序が正しいかどうか、テーブル名が正しいかどうか、フィールドが正しいかどうかなどを検証します。 、など。認証に失敗した場合は、直接エラーが返されます。認証に成功した場合は、そのまま次の処理に進みます。

• MySQL は、複数の SQL ステートメントが同じ意味を表現する可能性があるため、解析ツリー上でクエリの最適化を実行しますが、消費される時間は大幅に異なる可能性があります。したがって、MySQL はテーブルのストレージ エンジンに最適なステートメントの実行を見つけます。つまり、対応する実行プランを生成します。

• 上記で生成された実行プランを使用して、ストレージ エンジン層インターフェイスを呼び出します。これは私たちが通常使用する Explain であり、インデックスがインデックス化されているかどうか、消費された時間、その他の情報を確認するために使用できます。

• さまざまなストレージ エンジンが、対応する物理ストレージの場所に移動し、対応するデータを検索し、カプセル化して結果を返します。

• 結果セットが取得され、それが select ステートメントである場合、MySQL は次回同じ操作を実行することによるリソースの消費を避けるために結果をキャッシュに入れ、それを返します。クライアントの結果: この時点で、SQL ステートメントの実行プロセスは終了です。

MySQL 関連の技術記事の詳細については、MySQL チュートリアル 列にアクセスして学習してください。

以上がMySQL の全体的なアーキテクチャに関する簡単な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。