Mysql でステートメントを実行する全体のプロセスは何ですか?

1. Mysql の論理アーキテクチャ

Mysql の論理アーキテクチャは次のとおりで、全体はサーバー層とストレージ エンジン層の 2 つの部分に分かれています。

ストレージ エンジンに関係のない操作はサーバー層で完了し、ストレージ エンジン層がデータ アクセスを担当します。

レコードのクエリを例に、上図の処理に沿って各ステップの機能を紹介します。

2. コネクタ

このステップは主に接続と権限の検証を管理することです。

は、クライアントとコネクタの間で行われる mysql -u root -p などのクライアントの接続を管理する役割を果たします。接続は、長い接続と短い接続に分けられます。接続の確立は比較的複雑なプロセスであるため、長い接続を使用することをお勧めします。ただし、長い接続にも最適化の余地があるため、長い接続が多すぎると、大規模なクエリ操作が実行されるときにより多くのメモリが占​​有されます。

接続が確立された後、コネクタはユーザーの権限を決定し、ユーザーの操作は権限に基づいて許可されるかどうかを判断します。

3. アナライザー

このステップは主に字句解析と構文解析です。

字句解析は主にユーザーが何をしたいのかを判断するために使用されます。たとえば、select はクエリを意味します。

文法解析は主に、ユーザーが入力したSQLがMysqlの構文に準拠しているかどうかを判断することです。

4. オプティマイザー

アナライザーの後、Mysql はユーザーが何をしたいのかをすでに知っていますが、同じ SQL ステートメントに対して、それを Mysql で実装する方法は数多くある可能性があります。実装と効率は次のとおりです。も違います。

オプティマイザのステップでは、mysql は最適な効率を得るために実行方法を決定する必要があります。

5. Executor

このステップは主にエンジンを操作して結果を返すことです。ストレージ エンジン層を操作してデータ テーブルを走査し、基準を満たすデータを見つけてクライアントに返します。

6.更新ステートメントを実行する Mysql プロセス

SQL クエリ ステートメントと同じように、Mysql もコネクタ、アナライザー、オプティマイザー、エグゼキューター、およびストレージを通過する必要があります。エンジンはデータにアクセスするために使用されます。

#違いは、update ステートメントには、REDO ログと binlog という 2 つの重要なログ モジュールが関与する必要があることです。

7.redo log

レストランの経営は好調ですが、レストランである以上、日々のクレジット口座と借金の返済は避けられません。

多数の信用口座と借金返済がある場合、上司はピンクのボードを使用して 1 か月分の信用記録を記録することができなくなります。

そこで、上司は、すべての信用記録を台帳に書き込めると考え、ピンクのボードに書かれた内容は短期間であり、仕事を終えた後、ピンクのボードを使って次のことを行うと考えました。帳簿を照合します。

この例では、ピンクのボードは

redo log で、台帳は mysql のレコードです。返済の例えを使用して、mysql の更新プロセスを比較してみましょう。誰かがそれを毎日更新する場合このレコードは mysql で見つかりましたが、効率が非常に低いため、mysql の考えはこの上司と一致しています。更新操作は最初に redo ログ に配置され、そしてその後、しばらくしてからゆっくりと消化されます。

このアイデアは WAL テクノロジー、つまり

Write Ahead Logging テクノロジーと呼ばれ、最初にログを書き込んでからディスクに書き込みます。

ピンク色のボードがいっぱいで、上司がまだ仕事を終えていない場合、上司は自分のやっていることを止めなければなりません。 mysql の redo ログは合計 4GB の操作を記録できます

write pos が

check point に追いつくと、mysql のボスは次のことを行う必要があります。 REDO ログを処理します。

さらに、

redo ログ の永続性により、データベースが異常に再起動してもログが失われません。これは crash safe メカニズムですが、依然として必要ですREDO ログは innodb ストレージ エンジンに固有であることに注意してください。

8.bin log

Binlog はサーバー層のログで、すべてのストレージ エンジンに適用できます。

binlog があるのに、なぜ innodb ストレージ エンジン専用の REDO ログを作成する必要があるのでしょうか?

mysql には当初 innodb エンジンはなく、myisam エンジンがあり、binlog を使用していましたが、binlog はアーカイブに限定されており、クラッシュ セーフ メカニズムがなかったため、REDO ログを追加しました。

• redo ログは innodb ストレージ エンジンに固有であり、binlog はサーバー層に固有です。

• redo ログは物理ログを保存し、binlog論理ログです

#REDO ログは、上で説明したように、4GB のサイズをサポートしています。それ以上ある場合は、処理して上書きする必要があります。binlog ログには 1 つのログを入れる必要があります
ファイルの後に、新しいログ ファイルが作成されます。

以下では、ID 2 のデータ行の更新を例として取り上げます。

図のライト ボックスは、それが InnoDB 内で実行されることを示します。黒いボックスは、サーバーで実行されることを示します。

• エグゼキュータは、まずエンジンを検索して行 ID=2 を取得します。 ID が主キーであり、エンジンはツリー検索を直接使用してこの行を見つけます。 ID=2 行が配置されているデータ ページが既にメモリ内にある場合は、そのデータ ページが直接エグゼキュータに返されます。それ以外の場合は、ディスクからメモリに読み取ってから返す必要があります。

• エグゼキュータはエンジンによって与えられた行データを取得し、この値に 1 を加えます。たとえば、以前は N でしたが、現在は N 1 になり、新しい行を取得します。データを入力し、エンジン インターフェイスを呼び出して、「この行に新しいデータを入力してください」と書き込みます。

• エンジンは、この新しいデータ行をメモリに更新し、更新操作を REDO ログに記録します。この時点で、REDO ログは準備状態になります。次に、実行が完了し、いつでもトランザクションを送信できることを実行者に通知します。操作の実行中に、エグゼキュータはバイナリログを生成し、ディスクに書き込みます。

• エグゼキューターはエンジンのコミット トランザクション インターフェイスを呼び出し、エンジンは書き込まれたばかりの REDO ログをコミット状態に変更し、更新が完了します。

以上がMysql でステートメントを実行する全体のプロセスは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。