MySQL 学習のまとめ: InnoDB ストレージ エンジンのアーキテクチャ設計の予備的な理解

1. ストレージエンジン

前のセクションでは、SQL 実行プランは、エグゼキュータ コンポーネントがストレージ エンジン インターフェイスを呼び出すことによって完了することを説明しました。
すると、次のことがわかります。MySQL データベース管理システムは、データを保存するディスク ファイルと対話するためにストレージ エンジンに依存しています。

では、MySQL にはどのようなストレージ エンジンがあるのでしょうか?

主なものとしては、MyISAM、InnoDB、Memory などがあります。さて、InnoDB ストレージ エンジンはインターネット上で基本的に使用されているため、次に InnoDB ストレージ エンジンについての学習内容を簡単にまとめ、InnoDB ストレージ エンジン内のコンポーネントを簡単に紹介します。

バッファプール

データベースのデータはディスク ファイルに保存されることは誰もが知っています。
では、毎回ディスク ファイル内で直接テーブルを追加、削除、変更、クエリするのでしょうか?

答え: いいえ!

ディスク ファイルのランダム読み取りおよび書き込みパフォーマンスは非常に低いため、すべての操作をディスク上で実行すると、高性能な MySQL は存在せず、MySQL は高い同時実行性をサポートできず、インターネット上でそれほど人気が​​なくなります。

このとき、InnoDB ストレージ エンジンの最も重要なコンポーネントは、非常に重要なメモリ構造である緩沖池（Buffer Pool）です。これはメモリ内にあり、メモリの読み取りと書き込みのパフォーマンスが非常に高いため、MySQL は高い同時実行性をサポートできます。

バッファプールの使用原則:

まず、MySQL がリクエストを受信するプロセスを確認しましょう。

①. MySQLワーカースレッドは、データベース接続プールの接続を具体的に監視し、接続がある場合は接続内のSQL文を取得します。
②その後、SQL文はSQL 接口に渡されて処理され、SQLインターフェースでは以下の一連の処理が行われます。
③.查詢解析器SQL ステートメントを MySQL が理解できる形式に解析します。
④.查詢優化器、SQL ステートメントに最適な実行プランを作成します。
⑤.執行器実行プランに従ってストレージエンジンインターフェースを呼び出します。

上記は前回の記事の要約です。では、ストレージ エンジン インターフェイスは、追加、削除、変更、クエリをどのように実行するのでしょうか。更新操作を例に挙げると、他の操作も同様です。
まず、ストレージ エンジンは、更新 SQL に対応するデータ行が緩沖池（Buffer Pool）内にあるかどうかを判断します。存在する場合は、緩沖池（Buffer Pool）内で直接データを更新して返します。存在しない場合は、ディスク ファイルから緩沖池（Buffer Pool）にデータを読み込んで更新操作を実行し、最後に結果を返します。

3. ログファイルの元に戻す

トランザクションでは、トランザクションがコミットされる前であればいつでもデータの更新をロールバックできることは誰もが知っています。では、これを実行するために何を頼りにするのでしょうか?

undo 日志文件に依存します。

UNDO ログ ファイルの使用原則:

データの更新を例に挙げます。
id=100 のデータ行を更新し、フィールド名を「Zhang San」から「Li Si」に変更すると、2 つのキー情報「id=10」と「name=Zhang San」がundo 日志文件に書き込まれます。
トランザクションをコミットする前にロールバックする必要がある場合は、 undo 日志文件でこれらの 2 つのキーワードを見つけて、更新操作をロールバックします。

4. REDOログバッファ

前述のように、すべての追加、削除、変更、およびクエリ操作は実際にはバッファー プールで実行されるため、データの変更はディスク ファイルにすぐには反映されません。

そこで疑問が生じます。バッファ プール内のダーティ データがディスク ファイルにフラッシュバックされる前に MySQL がクラッシュしたらどうなるでしょうか。
このとき、InnoDB ストレージ エンジンは、 redo log bufferコンポーネントという非常に重要なコンポーネントを提供します。これはメモリ内のバッファでもあります。

REDOログバッファの使用原則:

上記の更新操作を例にとると、データが更新されると、データ更新のキー情報が記録され、それがREDOログに対応してredo log bufferに書き込まれます。

しかし、まだ問題があります。前述のように、 redo log bufferもメモリ内にあります。 MySQL がクラッシュすると、メモリ内のすべてのデータが失われるため、バッファ プール内のダーティ データとredo log buffer内のログも失われます。
この結果、クライアントは更新成功メッセージを受け取りますが、データベース内のデータは依然として正常に更新されないという状況が発生します。

したがって、 redo log bufferもディスク フラッシュ戦略があります。通常、トランザクションがコミットされると、 redo log buffer内のredo 日志ディスクにフラッシュバックされるため、トランザクションは正常にコミットされたが更新データが失われる可能性があるという問題を心配する必要はありません。緩沖池（Buffer Pool）内のダーティ データがディスクにフラッシュバックされる前に MySQL がクラッシュした場合でも、MySQL が再起動すると、ディスク上のredo 日志に基づいてダーティ データの以前の更新をすべて復元できるため、データは失われません。

要約する

以上が編集者が紹介したMySQL学習のまとめであり、InnoDBストレージエンジンのアーキテクチャ設計の予備的な理解です。お役に立てれば幸いです。