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 文を解析し、SQL によって完了される操作を理解する役割を担います。

オプティマイザ

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

まず、テーブル T で条件 C を満たすすべてのデータ行をフィルター処理し、フィールド f1 と f2 の値を結果セットとして選択します。
まず、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 での実行プロセスはどのようになるでしょうか。次のように：

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

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