MySQLステートメント実行プロセス

1.実行プロセスの1文の概要

クエリステートメント：パーミッション検証->キャッシュクエリ->アナライザー->オプティマイザー->エグゼキューター->パーミッション検証->エグゼキューター->エンジン。
更新ステートメント：アナライザー->パーミッション検証->エグゼキューター->エンジン->やり直し準備->ビンログ->やり直しコミット。

2.実行プロセスの詳細な説明

ここに画像の説明を挿入
MySQLは主に、サーバー層とストレージエンジン層の2つの部分に分かれています。

サーバーレイヤー：
コネクター、クエリキャッシュ、アナライザー、オプティマイザー、エグゼキューターを含みます。このレイヤーには、ストアドプロシージャ、トリガー、ビュー、関数などのすべてのクロスストレージエンジン機能と、一般的なログモジュールのbinlogが実装されています。。

コネクタ：ID認証および権限関連。
主に、検証コード、権限、およびその他の操作を含む、ユーザーログインデータベースおよびユーザーID検証を担当します。
クエリキャッシュ：クエリステートメントを実行すると、最初にキャッシュがクエリされます（MySQL8.0バージョンの後で削除されます）
1）このステップでは構文解析は行われません。
2）mysqlはステートメントを受信した後、コマンドディストリビューターを介してそれがクエリステートメントであるかどうかを判断します。
3）クエリキャッシュがオンになっている場合は、最初にキャッシュにクエリを実行して、SQLが完全に一致するかどうかを確認します。キャッシュは参照テーブル（Key-Value）に格納され、ハッシュ値によって参照されます。ハッシュ値Keyはクエリです。見積もり、クエリ自体、クエリ対象の現在のデータベース、クライアントプロトコルのバージョン、および返される結果に影響を与える可能性のあるその他の情報を含みます。キャッシュがヒットしたかどうかを判断するとき、mysqlはクエリステートメントを解析せず、直接使用します。 SQLステートメントとクライアント他の十分な元の情報を送信します。したがって、スペースやコメントなどの文字の違いにより、キャッシュミスが発生します。一致する場合は、現在のユーザーにクエリ権限があるかどうかを確認します。権限が確認されると、結果セット（値）はに直接返されます。クライアント。ダウン実行を続行します。
4）新しいバージョンでキャッシュが削除される理由：テーブルを更新するすべてのクエリキャッシュがクリアされるため、実際のビジネスシナリオではクエリキャッシュの無効化が非常に頻繁に発生する可能性があります。頻繁に更新されないデータの場合でも、キャッシュを使用することは可能です。
アナライザー：キャッシュヒットがない場合、SQLステートメントはアナライザーを通過して、ステートメントの構文が正しいかどうかを確認します。
1）キーワードの抽出、クエリテーブル、フィールド名、クエリ条件の抽出など。
2）それがmysql構文に準拠しているかどうかを判別します。
オプティマイザ：MySQLが考える最適な計画に従って実行します。
エグゼキュータ：ステートメントを実行してから、ストレージエンジンからデータを返します。
実行前にユーザー権限を確認する必要があります。権限がある場合はエンジンのインターフェースを呼び出して実行結果を返し、権限がない場合はエラーメッセージを返します。

ストレージエンジンレイヤー：
データの保存と読み取りを担当し、交換可能なプラグインアーキテクチャを採用し、MyISAM、InnoDB、Memoryなどの複数のストレージエンジンをサポートします。MySQLバージョン5.5.5以降、InnoDBがデフォルトのストレージエンジンとして使用され、InnoDBエンジンには独自のログモジュールがあります。

3、ログモジュール

ステートメントの更新を実行するときに、ログモジュールを導入する必要があります。Mysqlには独自のログモジュールbinlog（アーカイブログ）があり、すべてのストレージエンジンで使用できます。InnoDBエンジンにも独自のログモジュールREDOログ（やり直しログ）があります。更新ステートメントのフローは次のように要約できます
。1）データにキャッシュがあるかどうかを照会し、ある場合はキャッシュを使用します。
2）クエリステートメントを取得し、エンジンインターフェイスを呼び出して、データを書き込みます。InnoDBエンジンは、データをメモリに保存し、REDOログを記録します。このとき、REDOログは準備状態になり、エグゼキュータに実行を通知します。完了し、送信できます。
3）エグゼキュータは、通知を受信した後にbinlogを記録し、エンジンインターフェイスを呼び出して、送信状態としてREDOログを送信します。
4）更新が完了しました。

質問1：なぜ2つのログモジュールと1つのログモジュールを使用するのですか？
最初は、MySQLはInnoDBエンジンで動作しませんでした（InnoDBエンジンは他社によってMySQLにプラグインされました）。MySQL自体のエンジンはMyISAMですが、REDOログは一意であることがわかっています。 InnoDBエンジンと他のストレージエンジンに対しては、これによりクラッシュセーフ機能がなくなり（データベースが異常に再起動してもクラッシュセーフ機能が失われることはありません）、binlogログのみがアーカイブに使用できます。

質問2：REDOログとBINログを使用してデータの整合性を確保するにはどうすればよいですか？
MySQLの処理メカニズムによって保証されています。
1）REDOログが完了したかどうかを確認し、完了したらすぐに送信します。
2）REDOログが事前コミットのみでコミット状態にない場合は、binlogが完了しているかどうかを判断し、完了している場合はREDOログを送信し、不完全な場合はトランザクションをロールバックする必要があります。