MySQLの実行プロセスとシーケンスについての簡単な説明

はじめに: MySQL は、私たちが開発においてほぼ毎日直面するものです。開発におけるデータのソースとして、MySQL はデータの保存とデータの読み取りおよび書き込みを担当します。 MySQL を学習して理解することは非常に重要ですが、クライアントで SQL ステートメントを開始して詳細なクエリ データが表示されるまで、どのようなプロセスが実行されるのでしょうか。 MySQL サーバーはどのようにしてリクエストを処理し、SQL ステートメントを実行するのでしょうか?このブログでは、この問題について検討します。

1:mysql実行プロセス

mysql の全体的な実行プロセスを次の図に示します。

1.1: コネクタ

コネクタの主な役割は次のとおりです。

①クライアントとの通信を担当し、半二重モードです。つまり、一定の時間にクライアントのみがサーバーに要求するか、サーバーがクライアントにデータを送信できますが、同時には送信できません。MySQLはTC/IPを介してクライアントに接続されます。

②要求ユーザーのアカウントとパスワードが正しいかどうかを確認します。アカウントとパスワードが正しくない場合は、次のエラーが報告されます: ユーザー 'root'@'localhost' のアクセスが拒否されました (パスワードの使用: YES)

③ユーザーのアカウントとパスワードが検証されると、現在のユーザーの権限がMySQLの独自の権限テーブルで照会されます。

MySQL には、権限を制御する 4 つのテーブル分別為user表，db表，tables_priv表，columns_priv表,権限テーブルの検証プロセスは次のとおりです。

1: User表:ユーザーアカウント情報とグローバルレベル (すべてのデータベース) の権限を格納します。これにより、どのホストのどのユーザーがデータベースインスタンスにアクセスできるかが決まります。

• Db テーブル:數據庫級別権限を格納します。これにより、どのホストのどのユーザーがこのデータベースにアクセスできるかが決まります。
• Tables_priv テーブル:存放表級別的權限。これにより、どのホストのどのユーザーがデータベース内のこのテーブルにアクセスできるかが決まります。
• Columns_priv テーブル:存放列級別的權限。これにより、どのホストのどのユーザーがデータベース テーブル内のこのフィールドにアクセスできるかが決まります。
• Procs_priv テーブル:存放存儲過程和函數

2: まず、ユーザー テーブルの 3 つのフィールド (ホスト、ユーザー、パスワード) から、接続された IP、ユーザー名、パスワードが存在するかどうかを判断します。存在する場合は、検証に合格します。

3: ID 認証後、ユーザー、db、tables_priv、columns_priv の順に権限が割り当てられ、検証されます。つまり、まずグローバル権限テーブル user をチェックします。user 内の対応する権限が Y の場合、すべてのデータベースに対するこのユーザーの権限は Y となり、db、tables_priv、columns_priv はチェックされなくなります。N の場合は、db テーブル内のこのユーザーに対応する特定のデータベースをチェックし、db 内の権限 Y を取得します。db が N の場合は、tables_priv 内のこのデータベースに対応する特定のテーブルをチェックし、テーブル内の権限 Y を取得します。以下同様に続きます。

4: いずれかのプロセスで権限検証が失敗した場合、エラーが報告されます

1.2: キャッシュ

MySQL キャッシュの主な機能は、クエリの効率を向上させることです。キャッシュは、キーと値のハッシュ テーブルの形式で保存されます。キーは特定の SQL ステートメントであり、値は結果のコレクションです。キャッシュにヒットできない場合は、アナライザー ステップに進みます。キャッシュにヒットした場合は、クライアントに直接返されます。ただし、MySQL バージョン 8.0 以降では、キャッシュは正式に削除されたことに注意してください。削除の理由は、クエリ キャッシュが非常に頻繁に無効化されるためです。読み取りよりも書き込みが多い環境の場合、キャッシュは頻繁に追加および無効化されます。更新の負荷が大きい一部のデータベースでは、クエリ キャッシュのヒット率が非常に低くなります。キャッシュを維持するために、MySQL には特定のスケーラビリティの問題が発生する可能性があります。現在、バージョン 5.6 ではデフォルトで無効になっています。より推奨される方法は、キャッシュをクライアント上に置くことです。これにより、パフォーマンスが約 5 倍向上します。

1.3: アナライザー

アナライザーの主な機能は、クライアントから送信された SQL ステートメントを分析することです。これには、前処理と解析が含まれます。この段階では、SQL ステートメントのセマンティクスが分析され、キーワードと非キーワードが抽出され、解析されて解析ツリーが形成されます。具体的なキーワードには、select/update/delete/or/in/where/group by/having/count/limit などがありますが、これらに限定されません。分析中に構文エラーが見つかった場合は、例外が直接クライアントにスローされます: ERROR: SQL 構文にエラーがあります。

たとえば、 select * from user where userId =1234;

アナライザーでは、select from where などのキーワードが抽出され、セマンティック ルール ジェネレーターによって照合されます。MySQL はキーワードと非キーワードを自動的に判別し、ユーザーの一致するフィールドとカスタム ステートメントを識別します。この段階では、いくつかのチェックも実行されます。たとえば、現在のデータベースにユーザー テーブルが存在するかどうかのチェックなどです。userId フィールドが User テーブルに存在しない場合は、フィールド リストに不明な列があるというエラーも報告されます。

1.4: オプティマイザー

オプティマイザ ステージに入ることができるということは、SQL ステートメントが MySQL の標準セマンティック ルールに準拠しており、実行できることを意味します。このステージでは主に SQL ステートメントを最適化し、実行プランに基づいて最適な選択を行い、適切なインデックスを一致させて、最適な実行プランを選択します。たとえば、典型的な例は次のとおりです。

テーブル T では、列 A、B、C の結合インデックスを作成します。クエリを実行すると、SQL クエリ結果が select xx where B=x and A=x and C=x の場合。多くの人はインデックスが使用されていないと考えていますが、実際には使用されています。インデックスは左端の原則に従って使用する必要がありますが、本質的には、オプティマイザはこの SQL を where A=x and B=x and C=X に自動的に最適化します。この最適化により、基礎レイヤーがインデックスと一致するようになります。同時に、この段階で、実行プランに従って自動的に前処理されます。MySQL は各実行方法の最適な時間を計算し、最終的に実行された SQL を決定して最終エグゼキュータに渡します。

1.5: アクチュエータ

Executor ステージでは、ストレージ エンジン API が呼び出されます。API はストレージ エンジンを呼び出します。ストレージ エンジンには主に以下のものがありますが、MyISAM と InnoDB がよく使用されます。

このエンジンは以前は「テーブル プロセッサ」と呼ばれていました (実際、この名前の方が存在の意味をよく表していると思います)。特定のデータ ファイルの操作、選択や更新などの SQL のセマンティクスの分析、特定の操作の実行を担当します。実行後、特定の操作が binlog に記録されます。注意すべき点は、select は binlog に記録されず、update/delete/insert のみが binlog に記録されることです。更新は2フェーズコミット方式を使用し、レコードはすべてREDOログに保存されます。

2: 実行ステータス

show full processlist コマンドを使用すると、すべての処理プロセスを表示できます。これには主に、クライアントを処理するサーバーのステータスを示す以下のステータスが含まれます。ステータスには、ロック プロセス、統計ストレージ エンジン情報、データのソート、中間テーブルの検索、データの送信など、要求を開始したクライアントからバックグラウンド サーバーの処理までのプロセスが含まれます。これは MySQL のすべての状態をカバーしており、具体的な意味は次のとおりです。

3: SQL実行順序

実際、SQL は記述した順序どおりに前から後ろへ、または左から右へ実行されるわけではありません。SQL は固定された順序で解析されます。SQL の主な機能は、前のステージからの結果を返します。次のステージでの使用を目的としています。SQL は実行中にさまざまな一時中間テーブルを持ちますが、通常は次の順序になります。

例: select distinct s.id from T t join S s on t.id=s.id where t.name="Yrion" group by t.mobile having count(*)>2 order by s.create_time limit 5;

3.1: から

最初のステップは、from キーワードに続いてテーブルを選択することです。これは、データベースからどのテーブルを実行するかを指定する、SQL 実行の最初のステップでもあります。

例の説明: この例では、まずデータベースからテーブルTを検索します。

3.2: 参加する

join は関連付けるテーブルを示し、on は接続の条件です。実行する必要があるデータベース テーブル T と S が from と join on を通じて選択され、直積が生成され、T と S をマージする一時的な中間テーブル Temp1 が生成されます。 on: テーブルのバインド関係を決定し、on を通じて一時的な中間テーブル Temp2 を生成します。

例の説明: テーブル S を検索し、一時的な中間テーブル Temp1 を生成し、次にテーブル T で S と同じ ID を持つ部分を検索して、テーブル Temp2 を形成します。このテーブルには、T と同じ ID を持つすべてのデータが含まれます。

3.3:どこで

where はフィルタリングを意味し、where の後の条件に従ってフィルタリングが実行され、指定されたフィールドの値に従って一時中間テーブル Temp2 から必要なデータがフィルタリングされます (and コネクタがある場合は、ジョイント フィルタリングが実行されます)。この段階でデータが見つからない場合は、クライアントに直接返され、それ以上先に進まないことに注意してください。このプロセスにより、一時中間テーブル Temp3 が生成されます。 whereでは集計関数を使用できないことに注意してください。集計関数は主に（min\max\count\sumなどの関数）です。

例の説明: temp2 一時テーブル コレクションで、名前が "Yrion" のテーブル T のデータを検索します。データが見つかると、名前列 "Yrion" のすべてのテーブル データを含む一時中間テーブル Temp3 になります。

3.4: グループ化

Group by はグループ化することであり、where 条件でフィルタリングした後の一時テーブル Temp3 を固定フィールドに従ってグループ化して、一時中間テーブル Temp4 を生成します。このプロセスでは、データの順序のみが変わり、データの総量は変わりません。テーブル内のデータはグループの形式で存在します。

例の説明: temp3 テーブル データ内のモバイルをグループ化し、モバイルの同じデータを検索し、それらをまとめて temp4 一時テーブルを生成します。

3.5:持つ

カウント可能な一時中間テーブルTemp4を集計し、中間テーブルTemp5を生成します。この段階では、選択でエイリアスを使用できます。

例の説明: temp4 一時テーブルで 2 つ以上のエントリを持つデータを検索します。2 未満の場合は、直接破棄され、一時中間テーブル temp5 が生成されます。

3.6:選択

グループ化・集計されたテーブルからクエリするデータを選択します。 * の場合は、すべてのデータとして解析され、中間テーブル Temp6 が生成されます。

例の説明: この段階では、temp5 一時集計テーブルの S テーブルの id がフィルター処理されて Temp6 が生成されます。この時点で、temp6 には s テーブルの id 列データと name="Yrion" のみが含まれます。モバイル グループ内の 2 より大きい数値を持つデータ

3.7:明確な

Distinct はすべてのデータから重複を削除します。min 関数と max 関数がある場合は、フィールド関数の計算が実行され、一時テーブル Temp7 が生成されます。

例の説明: この段階では、temp5 のデータが重複排除されます。エンジン API は重複排除関数を呼び出してデータをフィルタリングし、最終的に ID が初めて出現するデータのみを保持し、一時的な中間テーブル temp7 を生成します。

3.8:並べ替え

Temp7 に従って順番にまたは逆順にソートされ、一時中間テーブル Temp8 に挿入されます。このプロセスはより多くのリソースを消費します。

例の説明: これにより、temp7 一時テーブル内のすべてのデータが作成時間 (create_time) でソートされ、このプロセスで列や行が失われることはありません。

3.9:制限

Limit は中間テーブル Temp8 をページ分割し、一時中間テーブル Temp9 を生成して、クライアントに返します。

例の説明: temp7 のデータをソートし、最初の 5 つのレコードを取得して一時テーブル Temp9 に挿入し、最後にクライアントに返します。

ps: 実際、このプロセスは絶対にこのようになるわけではありません。MySQLは、見つかったデータセットを選択するなど、最高の最適化効果を達成するために途中でいくつかの最適化を行います。

IV. 要約

このブログでは、MySQL の実行プロセスと SQL の実行順序についてまとめています。これらを理解することで、SQL 文を最適化し、MySQL での SQL 文の記述から最終実行までの軌跡を理解するのに役立ちます。これにより、SQL をより深く詳細に理解し、データベースを理解する能力を向上させることができます。同時に、複雑な SQL の実行プロセスや記述にも一定の意義を持つことになります。

これで、MySQL の実行プロセスとシーケンスに関するこの記事は終了です。MySQL の実行プロセスとシーケンスに関するより関連性の高いコンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。