【MySQL】MySQLの論理アーキテクチャ

MySQL のさまざまなコンポーネントがどのように連携して動作するかを頭の中でアーキテクチャ図を構築できれば、MySQL サーバーについてより深く理解できるようになります。

トップレベルのサービスは MySQL に固有のものではなく、ほとんどのネットワークベースのクライアント/サーバー ツールは同様のアーキテクチャを持っています。接続処理、認可認証、セキュリティなど。

第 2 層のアーキテクチャは、MySQL のより興味深い部分です。 MySQL のコア サービス関数のほとんどは、クエリ解析、分析、最適化、キャッシュ、およびすべての組み込み関数 (たとえば、日付、時刻、数学関数、暗号化関数など) を含め、この層にあります。この層の実装: ストアド プロシージャ、トリガー、ビューなど。

3 番目の層にはストレージ エンジンが含まれています。ストレージ エンジンは、MySQL でのデータの保存と取得を担当します。 GNU/Linux のさまざまなファイル システムと同様、各ストレージ エンジンには長所と短所があります。サーバーは API を介してストレージ エンジンと通信します。これらのインターフェイスは、異なるストレージ エンジン間の違いを保護し、上位層のクエリ プロセスに対してこれらの違いを透過的にします。ストレージ エンジン API には、「トランザクションの開始」や「主キーに基づいたレコード行の抽出」などの操作を実行するための低レベル関数が十数個含まれています。ただし、ストレージ エンジンは SQL を解析しません (注: InnoDB は例外で、MySQL サーバー自体がこの機能を実装していないため、外部キー定義を解析します)。また、異なるストレージ エンジンは相互に通信せず、単に応答します。上位層のサーバーリクエストに送信します。

接続管理とセキュリティ

各クライアント接続にはサーバー プロセス内のスレッドがあり、この接続のクエリは、特定の CPU コアまたは CPU でのみ実行されます。サーバーはスレッドのキャッシュを担当するため、新しい接続ごとにスレッドを作成または破棄する必要はありません。 (注: MySQL 5.5 以降では、スレッド プール プラグインをサポートする API が提供されており、プール内の少数のスレッドを使用して多数の接続を処理できます)。

クライアント (アプリケーション) が MySQL サーバーに接続するとき、サーバーはそれを認証する必要があります。認証は、ユーザー名、元のホスト情報、およびパスワードに基づいて行われます。セキュア ソケット (SSL) 接続を使用する場合は、X.509 証明書認証も使用できます。クライアントが正常に接続すると、サーバーはクライアントに特定のクエリに対する権限があるかどうか (たとえば、クライアントがワールド データベースの国テーブルに対して SELECT ステートメントを実行できるかどうか) を引き続き検証します。

最適化と実行

MySQL はクエリを解析して内部データ構造 (解析ツリー) を作成し、クエリの書き換え、テーブルの読み取り順序の決定、適切なインデックスの選択など、さまざまな最適化を実行します。ユーザーは、特別なキーワードのヒントを通じて、オプティマイザーの意思決定プロセスに影響を与えることができます。また、最適化プロセスのさまざまな要素の説明をオプティマイザーに要求して、ユーザーがサーバーが最適化の決定をどのように行うかを知ることができ、ユーザーがクエリとスキーマを再構築し、関連する構成を変更してアプリケーションを可能な限り効率的に実行します。

オプティマイザーは、使用されるストレージ エンジンを気にしませんが、ストレージ エンジンはクエリの最適化に影響を与えます。オプティマイザーは、ストレージ エンジンに対して、特定の操作の容量やコスト情報、テーブル データなどの統計情報の提供を要求します。たとえば、特定のストレージ エンジンの特定のインデックスが特定のクエリに対して最適化される場合があります。

SELECT ステートメントの場合、サーバーはクエリを解析する前に、まずクエリ キャッシュ (クエリ キャッシュ) をチェックします。対応するクエリが見つかった場合、サーバーはクエリの解析、最適化、およびクエリのプロセス全体を実行する必要はありません。実行されますが、キャッシュ内の結果セットを直接返します。

MySQL のさまざまなコンポーネントがどのように連携するかを頭の中でアーキテクチャ図を構築できれば、MySQL サーバーについての理解を深めるのに役立ちます。

トップレベルのサービスは MySQL に固有のものではなく、ほとんどのネットワークベースのクライアント/サーバー ツールは同様のアーキテクチャを持っています。接続処理、認可認証、セキュリティなど。

第 2 層のアーキテクチャは、MySQL のより興味深い部分です。 MySQL のコア サービス関数のほとんどは、クエリ解析、分析、最適化、キャッシュ、およびすべての組み込み関数 (たとえば、日付、時刻、数学関数、暗号化関数など) を含め、この層にあります。この層の実装: ストアド プロシージャ、トリガー、ビューなど。

3 番目の層にはストレージ エンジンが含まれます。ストレージ エンジンは、MySQL でのデータの保存と取得を担当します。 GNU/Linux のさまざまなファイル システムと同様、各ストレージ エンジンには長所と短所があります。サーバーは API を介してストレージ エンジンと通信します。これらのインターフェイスは、異なるストレージ エンジン間の違いを保護し、上位層のクエリ プロセスに対してこれらの違いを透過的にします。ストレージ エンジン API には、「トランザクションの開始」や「主キーに基づいたレコード行の抽出」などの操作を実行するための低レベル関数が十数個含まれています。ただし、ストレージ エンジンは SQL を解析しません (注: InnoDB は例外で、MySQL サーバー自体がこの機能を実装していないため、外部キー定義を解析します)。また、異なるストレージ エンジンは相互に通信せず、単に応答します。上位層のサーバーリクエストに送信します。

接続管理とセキュリティ

各クライアント接続にはサーバー プロセス内のスレッドがあり、この接続のクエリは、特定の CPU コアまたは CPU でのみ実行されます。サーバーはスレッドのキャッシュを担当するため、新しい接続ごとにスレッドを作成または破棄する必要はありません。 (注: MySQL 5.5 以降では、スレッド プール プラグインをサポートする API が提供されており、プール内の少数のスレッドを使用して多数の接続を処理できます)。

クライアント (アプリケーション) が MySQL サーバーに接続するとき、サーバーはそれを認証する必要があります。認証は、ユーザー名、元のホスト情報、およびパスワードに基づいて行われます。セキュア ソケット (SSL) 接続を使用する場合は、X.509 証明書認証も使用できます。クライアントが正常に接続すると、サーバーはクライアントに特定のクエリに対する権限があるかどうか (たとえば、クライアントがワールド データベースの国テーブルに対して SELECT ステートメントを実行できるかどうか) を引き続き検証します。

最適化と実行

MySQL はクエリを解析して内部データ構造 (解析ツリー) を作成し、クエリの書き換え、テーブルの読み取り順序の決定、適切なインデックスの選択など、さまざまな最適化を実行します。ユーザーは、特別なキーワードのヒントを通じて、オプティマイザーの意思決定プロセスに影響を与えることができます。また、最適化プロセスのさまざまな要素の説明をオプティマイザーに要求して、ユーザーがサーバーが最適化の決定をどのように行うかを知ることができ、ユーザーがクエリとスキーマを再構築し、関連する構成を変更してアプリケーションを可能な限り効率的に実行します。

オプティマイザーは、使用されるストレージ エンジンを気にしませんが、ストレージ エンジンはクエリの最適化に影響を与えます。オプティマイザーは、ストレージ エンジンに対して、特定の操作の容量やコスト情報、テーブル データなどの統計情報の提供を要求します。たとえば、特定のストレージ エンジンの特定のインデックスが特定のクエリに対して最適化される場合があります。

SELECT ステートメントの場合、サーバーはクエリを解析する前に、まずクエリ キャッシュ (クエリ キャッシュ) をチェックします。対応するクエリが見つかった場合、サーバーはクエリの解析、最適化、およびクエリのプロセス全体を実行する必要はありません。実行されますが、キャッシュ内の結果セットを直接返します。

上記は [MySQL] MySQL 論理アーキテクチャの内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。