MySQL InnoDB アーキテクチャの概要

導入

バックエンド プログラマーとして、私たちはほぼ毎日データベースを扱わなければなりません。市場には、Mysql、Oracle、SqlServer など、多くのデータベースがあります。では、私たちのプログラムはどのようにしてデータベースに接続するのでしょうか?それがデータベース ドライバーです。異なるデータベースには異なるデータベース ドライバーが対応します。データベースに接続するときは、まずデータベース ドライバーを登録し、次にデータベース アドレス、ユーザー名、パスワードなどの情報に基づいてデータベースとの接続を確立します。 Maven を使用してプロジェクトを管理する場合、通常は次の構成が表示されます。

<依存関係>
  <グループID>mysql</グループID>
  <artifactId>mysql-コネクタ-java</artifactId>
  <バージョン>8.0.24</バージョン>
</依存関係>

上記のように、Maven を介して MySQL ドライバー jar パッケージをインポートすると、プロジェクト内の SQL ステートメントを介してデータベースを操作できるようになります。では、リクエストを受け取った後、データベースはどのように実行されるのでしょうか?次にMySQLデータベースを通じて詳しく説明します。

1. MySQLデータベースの全体的なアーキテクチャ

一般的に、Web プロジェクトが開発された後、プロジェクト ファイルを war パッケージにパッケージ化し、Tomcat コンテナーを通じて公開して、最終的にユーザーがシステムにアクセスできるようになることがわかっています。 Tomcat が同時アクセスをサポートしていることは誰もが知っています。複数のリクエストが同時にデータベースを操作する必要がある場合、複数のリクエストがデータベース接続を取得する必要がありますか?それは絶対にそうではありません。そうでないと、効率が非常に低くなります。リクエストごとに接続を確立し、リクエストが完了したら接続を破棄する必要がありますか?それは絶対にそうではありません。接続の頻繁な確立と破棄は、間違いなくパフォーマンスに影響します。では、Tomcat はこの問題をどのように解決するのでしょうか? スレッド プールについて説明したときに言及した「プーリング」という概念を覚えていますか?はい、Tomcatにはデータベース接続プールがあるので、同じデータベースサーバーにも対応するデータベース接続プールがあります。一般的な構造は下の図に示されています。

SQL インターフェース

リクエストがデータベースに到達すると、リスニング スレッドによって検出され、その後、リクエストは処理のために SQL インターフェイスに転送されます。SQL インターフェイスは、特に追加、削除、変更、クエリなどの SQL ステートメントを実行するために使用されます。

パーサー

SQL 文は私たちにとっては比較的理解しやすいものですが、MySQL システムでは直接理解できないため、SQL インターフェイスは SQL 文をパーサーに転送します。クエリ パーサーは SQL 文の解析、つまり確立された SQL 構文に従って SQL 文を解析し、S​​QL によって完了される操作を理解する役割を担います。

オプティマイザ

パーサーは、SQL ステートメントが完了する必要がある操作を理解した後、オプティマイザーを使用して最適と思われるパスを選択します。一般的に言えば、特定の結果を達成するには複数のパスがあります。たとえば、条件 C を満たすテーブル T の 2 つのフィールド f1 と f2 の値を照会する場合、少なくとも 2 つのパスが考えられます。

1. まず、テーブル T で条件 C を満たすすべてのデータ行をフィルター処理し、フィールド f1 と f2 の値を結果セットとして選択します。
2. まず、f1 と f2 のすべての値を選択し、次に条件 C に従って条件を満たすデータ行をフィルタリングして結果セットを形成します。
   

オプティマイザーは、さまざまな戦略に基づいて最適であると判断したクエリ パスを取得します。

アクチュエータ

オプティマイザーが最適なクエリ パスを選択した場合、最終的に必要な結果を得ることができないため、依然としてエグゼキューターを使用する必要があります。エグゼキュータの役割は、オプティマイザによって選択された最適なクエリ パスに基づいて実行プランを生成し、データベース ストレージ エンジンによって提供されるインターフェイスを継続的に呼び出して、SQL ステートメントの実行プランを完成させることです。

ストレージエンジン

データベースは通常、メモリまたはディスクの 2 つの場所にデータを保存します。では、データをクエリする場合、エグゼキュータはディスクまたはメモリをクエリする必要がありますか?メモリはどのように照会されますか?ディスクはどのように検索されますか? メモリ容量には制限があります。メモリに余分なスペースがない場合はどうすればいいですか?一連の問題の解決策はストレージ エンジンです。MySQL は、InnoDB、MyISAM、MEMORY など、複数のストレージ エンジンを提供しています。より一般的なのは InnoDB と MyISAM です。現在の MySQL データベースのストレージ エンジンは、show engines コマンドで表示できます。このシリーズでは、主に InnoDB ストレージ エンジンを分析します。

要約すると、SQL文の実行フローの完全なセットは次の図に示されています。

2. InnoDB ストレージ エンジン アーキテクチャ

SQL ステートメントが上記のプロセスを経て、エグゼキュータが InnoDB ストレージ エンジンを呼び出すインターフェイスに到達した場合、InnoDB ストレージ エンジンはどのように動作するのでしょうか。

メモリバッファプール

まず、InnoDB ストレージ エンジンの最初の重要なコンポーネントであるメモリ バッファー プール (バッファー プール) を紹介します。これは、クエリや更新などの操作を容易にするために大量のデータを格納するメモリ内の領域です。これを実行する目的は、SQL 文の実行効率を向上させることであるため、クエリ、更新、その他の操作がすべてバッファー プール内で完了することを明確にする必要があります (バッファー プールにデータが存在するかどうかに関係なく、存在する場合は直接操作し、存在しない場合はディスクからバッファー プールにロードしてから操作します)。

元に戻すログ ログファイル

データベースに精通している学生は、データを更新するときは通常、トランザクションで実行することを知っています。トランザクションには、ACID という 4 つの主な特性があります。A はアトミック性 (操作が完全に成功するか、完全に失敗するかのいずれか) を表します。成功した場合、トランザクションはコミットされ、失敗した場合はロールバックされます。ロールバックは、UNDO ログによって実行されます。 （一度聞かれたことがあったのですが、緊張しすぎて覚えていませんでした。気づくのに時間がかかりました…）。

通常、MySQL データベースはデフォルトで自動トランザクション コミットを有効にするため、追加の操作を行う必要はありません。set autocommit = 0 で自動トランザクション コミットをオフにし、set autocommit で自動トランザクション コミットをオンにすることができます。興味があれば、ぜひ体験してみて下さい。

redolog ログファイル

前にも紹介したように、更新操作はバッファプール、つまりメモリ内で完了します。操作後に MySQL がクラッシュすると、メモリ内の変更されたデータは必然的に失われます。この問題を解決するために、InnoDB アーキテクチャでは、変更したデータを記録するように REDO ログが設計されています。 MySQL がクラッシュした場合は、再起動後に REDO ログを使用してデータを回復できます。ただし、REDO ログは最初にメモリ内の REDO ログ バッファに書き込まれ、ディスクには保存されないため、データ損失のリスクは依然として存在します。そのため、InnoDB はいくつかの REDO ログ フラッシュ戦略を提供しています。フラッシュ戦略は innodb_flush_log_at_trx_commit を通じて設定できます。たとえば、innodb_flush_log_at_trx_commit=1 は、トランザクション コミット ログがすぐにディスクにフラッシュされることを意味します。この方法では、データ損失のリスクはありませんが、パフォーマンスは確実に影響を受けます。一般的に、ビジネスニーズに基づいてポリシーを設定できます。

binlog ログファイル

Binlog はアーカイブ ログとも呼ばれます。Redo ログとは異なり、MySQL サーバー用であり、InnoDB に固有のものではありません。通常、ユーザーは特定の時点のデータを復元したり、マスター スレーブ同期を行ったりしますが、Redo ログ ユーザーは障害から回復します。通常、トランザクションが送信されるとアーカイブ ログも送信されます。アーカイブ ログには、ディスク フラッシュ戦略もいくつかあります。Sync_binlog は、複数のトランザクション コミット後のディスク フラッシュを制御するために使用されます。特別な sync_binlog=0 は、フラッシュのタイミングが MySQL ではなくオペレーティング システムによって制御されることを意味します。

InnoDB 実行プロセス

InnoDB ストレージ エンジンのいくつかのコンポーネントを紹介した後、データの一部を更新する必要があるとします。InnoDB での実行プロセスはどのようになるでしょうか。次のように：

1. データがバッファ プールに存在しない場合は、ランダム I/O によってディスクからデータが読み取られ、バッファ プールに格納されます。
2. データをロールバックするために UNDO ログを書き込みます。
3. バッファ プール内のデータを更新します。
4. 障害回復データ用の REDO ログを REDO ログ バッファに書き込みます。
5. トランザクションをコミットする準備をし、ポリシーに基づいて REDO ログをディスクにフラッシュします。
6. トランザクションをコミットする準備をし、ポリシーに基づいて binlog ログをディスクにフラッシュします。
7. binlog ファイルとコミット マークを redo ログ ファイルに書き込みます。
8. トランザクションをコミットします。
9. バックグラウンド IO スレッドは、バッファー プール内のダーティ データをディスクに入力します。 (初期段階ではバッファプール内のログのみが変更され、ディスク内のデータは変更されていないため、バッファプール内のデータはディスクデータに対してダーティデータとなります)
   

プロセスを以下の図に示します。

上記はMySQL InnoDBアーキテクチャの詳細な概要です。MySQL InnoDBアーキテクチャの詳細については、123WORDPRESS.COMの他の関連記事に注目してください。