MySQL アーキテクチャ コンポーネントとは

この記事では、MySQL アーキテクチャ コンポーネントについて紹介します。一定の参考値があるので、困っている友達が参考になれば幸いです。

全体的なアーキテクチャ

1. コネクタ

コネクタは主に接続の確立を担当します。接続、権限の検証、および管理接続については、コマンド show processlist を使用して接続情報を表示できます。ユーザー接続が正常に作成されると、権限情報がメモリに読み込まれます。後でユーザーの権限を変更した場合、更新しないと変更が反映されません。

コネクションは、長時間指示がない（アイドル状態）と、一定時間後にコネクタがリンクを切断します。この時間はパラメータ wait_timeout によって制御され、デフォルトは 8 時間です。

コネクタ内の接続は、長い接続と短い接続に分けられます。

• 長い接続: 接続が成功した後、クライアントは同じ接続の使用を要求します

• ショート接続: リクエストが実行されるたびに接続が切断され、別のリクエストがあれば接続が再確立されます。 , 一般に、接続を頻繁に繰り返し作成することによるオーバーヘッドは避けたいと考えていますが、使用される接続が長いということは、接続が切断されることなく長時間維持されることを意味します。ただし、接続は使用中に占有されるメモリの一部を管理し、接続が切断されると接続とともに解放されることに注意してください。接続が切断されず、長時間処理されずに蓄積され続けると、メモリの過剰使用が発生し、システムによって強制終了される可能性があります。一般に、解決策は 2 つあります。

長い接続を定期的に切断し、一定期間が経過した後、または大量のメモリを消費するクエリの実行後に切断することで、クエリの実行時にメモリを解放します。時間が来たら、接続を再作成します

• 5.7 以降のバージョンでは、mysql_reset_connection を使用して、再接続や権限の検証を行わずに接続リソースを再初期化し、接続を接続時の状態に復元できます。それは作られた。同時に、テーブル ロックの解放、一時テーブルのクリア、セッションに設定された変数のリセットなど、他の効果も発生します。

• 2. クエリ キャッシュ

注: バージョン 8.0 以降、クエリ キャッシュは廃止されました。

接続が正常に作成された後、SQL ステートメントを実行できるようになりますが、クエリ キャッシュがオンになっている場合、クエリはクエリからクエリされます。 SQLが実際に解析される前のキャッシュ、キャッシュがヒットした場合は直接返されます。クエリ キャッシュは Key-Value 構造で、Key は SQL ステートメント、Value は対応するクエリ結果です。キャッシュが見つからない場合でも、後続のクエリ操作は続行されます。クエリが完了すると、結果はクエリ キャッシュに保存されます。

クエリキャッシュが削除されるのはなぜですか？なぜなら、クエリのキャッシュは通常、良いことよりも害の方が多いからです。テーブルが更新されると、そのテーブルに対応するクエリ キャッシュがクリアされますが、頻繁に更新されるテーブルの場合、クエリ キャッシュは非常に頻繁に無効化され、基本的に効果がなく、キャッシュ更新のオーバーヘッドも発生します。システム構成テーブルなど、基本的に変更されないデータ テーブルの場合は、クエリ キャッシュの使用を選択できます。このようなテーブルのキャッシュ ヒット率は高く、利点が欠点を上回る可能性があります。ただし、この構成では、次のことが可能です。外部キャッシュも使用します。

クエリ キャッシュは、パラメータ query_cache_type を通じて設定できます。このパラメータには、次の 3 つのオプションの値があります:

# 0: クエリ キャッシュをオフにする

#1: クエリ キャッシュをオンにする
2: SQL に SQL_CACHE キーワードがある場合、クエリ キャッシュを使用します。たとえば、select SQL_CACHE * from t where xxx;
3. アナライザー

• クエリ キャッシュがヒットしない場合は、SQL を実際に実行する必要があり、実行前に SQL を解析する必要があります。この解析は主に字句解析に分けられます。分析と構文分析の 2 つのステップ。

字句解析: SQL から select、from、テーブル名、フィールド名などのキーワードを抽出します。

文法解析:字句解析の結果と MySQL によって定義されたいくつかの文法規則により、SQL 文法が正当であるかどうかがチェックされ、最終的に抽象構文ツリー (AST) が生成されます
4. オプティマイザー

• オプティマイザーは、アナライザーによって生成された AST を入力として受け取り、SQL を最適化し、オプティマイザーが最適な実行プランと考えるものを生成し、それを実行のためにエグゼキューターに渡します。最適化プロセスには、SQL の論理変換とコスト計算が含まれます。

論理変換は Java の静的コンパイル時の最適化に似ており、SQL を「簡素化」して SQL 変換の前後で一貫した実行結果を保証します。たとえば、1=1 および a.id = 2 は、a.id = 2 と同等になります。

コスト計算の主な目的は、インデックスを使用するかどうか、どのインデックスを使用するか、複数テーブル接続に使用する順序など、SQL の実行方法を選択することです。コストはサービス層のコストとエンジン層のコストに分かれており、サービス層のコストは主にCPUに関係し、エンジン層のコストは主にディスクI/Oに関係します。 MySQL 5.7 では、この 2 つのコストを設定するための 2 つのシステム テーブル mysql.server_cost と mysql.engine_cost が導入されており、テーブルに設定されるのは、一時テーブルの作成、ソート、ページ読み取りなどのさまざまな操作に対応するコストです。

オプティマイザーは、生成されたクエリ プランと上記 2 つのコスト構成に基づいてクエリ プランの最終的なコストを計算し、複数のクエリ プランの中からエグゼキューターへのコストが最も小さいものを選択して実行します。ただし、コストが最小であることが必ずしも実行時間の最短を意味するとは限らないことに注意してください。

5. エグゼキュータ

エグゼキュータは、オプティマイザによって選択されたクエリ プランに従って SQL を実行します。実行前に、要求元のユーザーが対応するクエリ権限を持っているかどうかも確認し、最後にMySQL エンジン層を呼び出す SQL ステートメントを実行して結果を返すインターフェイスを提供します。クエリ キャッシュが有効になっている場合、結果もクエリ キャッシュに保存されます。

関連する推奨事項: 「mysql チュートリアル 」

以上がMySQL アーキテクチャ コンポーネントとはの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。