この記事では、mysql に関する関連知識をお届けします。主にストレージ エンジン InnoDB アーキテクチャに関する関連コンテンツを紹介します。InnoDB は、トランザクション セキュリティをサポートするストレージ エンジンである MySQL のデフォルト エンジンです。それを見て、皆さんのお役に立てれば幸いです。
推奨学習: mysql ビデオ チュートリアル
現在の MySQL8.x バージョンのデータベースはすでに多くのストレージ エンジンをサポートしていますが、一般的には固定的な考え方が形成されやすく、他のストレージ エンジンを簡単に採用できないため、ストレージを最適化する多くの機能が欠けています。したがって、現在サポートされている 9 つのデータベース ストレージ エンジンの機能を明確に理解することを学ぶ価値があります。この記事では、これら8つのデータベースストレージエンジンの機能や機能、利用シーンをわかりやすく解説します。
この一連の記事は、私のコラム「さまざまな SQL データベース操作をすぐに学ぶ」に掲載されます。基本的に、日常業務、従来のクエリ データベース分析、および複雑な操作を処理するための SQL の使用に関するすべての側面をカバーしています。データベースとテーブルを構築する基本的な手順から、さまざまな複雑なデータベース操作の処理、一般的な SQL 関数の専門的な説明まで、作成には多くの時間と労力が費やされています。データ開発については、最も実践的でよく使われる知識を初めて学ぶコラムの購読をお勧めします。このブログは非常に長いので、よく読んで練習する必要がありますが、最良の部分を選択して実践方法を詳しく説明します。ブロガーは長期にわたってブログ記事を管理していきますので、間違いや疑問がございましたら、コメント欄でご指摘いただければ幸いです。
MySQL データベースにアクセスしてストレージ エンジンを表示すると、MySQL データベースでサポートされているすべてのストレージ エンジンを確認できます:
SHOW ENGINES
現在、Federated がサポートしていないエンジンがあります。他の 8 つのデータベース ストレージについてのみ明確にする必要があります。
MySQL の一般的なデータベース エンジンには、MyISAM、InnoDB、Memory などがあります。それでは、まずこれら 3 つのエンジンについて理解しましょう。
InnoDB は MySQL のデフォルト エンジンであり、トランザクション セキュリティをサポートするストレージ エンジンです。 MySQL のデータは物理ディスクに保存され、実際のデータ処理はメモリ内で実行されます。ディスクの読み取りおよび書き込み速度は非常に遅いため、操作ごとに頻繁にディスクの読み取りおよび書き込みが行われると、パフォーマンスが非常に低下します。
上記の問題を解決するために、InnoDB は、ディスクとメモリ間の対話の基本単位としてページを使用して、データを複数のページに分割します (一般的なページ サイズは 16 KB)。この場合、一度に少なくとも 1 ページのデータがメモリに読み込まれるか、1 ページのデータがディスクに書き込まれます。メモリとディスク間のやり取りの数を減らすことで、パフォーマンスを向上させます。
これは本質的に典型的なキャッシュ設計の考え方です。一般に、キャッシュ設計は基本的に時間次元または空間次元から検討されます:
時間次元: データの場合が使用されている場合、次の期間に再び使用される可能性が高くなります。ホットスポット データ キャッシュは、このアイデアの実装に属すると考えることができます。
空間次元: あるデータが使用されている場合、その近くに保存されているデータもすぐに使用される可能性が高くなります。 InnoDB のデータ ページとオペレーティング システムのページ キャッシュは、このアイデアを具体化したものです。
以下は公式の InnoDB エンジン構造図です。主にメモリ構造とディスク構造の 2 つの部分に分かれています。
メモリ構造には主に、バッファ プール、変更バッファ、アダプティブ ハッシュ インデックス、ログ バッファの 4 つのコンポーネントが含まれています。
バッファプールは、データ、インデックス、挿入バッファ、アダプティブハッシュインデックス、ロック情報、データディクショナリで構成されます。バッファー プール。BP と呼ばれます。 BP はページに基づいており、デフォルト サイズは 16K です。BP の最下層は、リンク リスト データ構造を使用してページを管理します。 InnoDB がテーブル レコードとインデックスにアクセスすると、それらはページ ページにキャッシュされ、後で使用することでディスク IO 操作が軽減され、効率が向上します。
バッファ プールは、データベースのパフォーマンスに対する遅いディスク速度の影響を補うためにメモリの速度を使用する単なるメモリ領域です。データベースのページを読み取る場合、まずディスクから読み取ったページをバッファプールに格納しますが、この処理をページをバッファプールに「FIX」と呼びます。次回同じページが読み取られるときは、まずそのページがバッファ プール内にあるかどうかを確認します。ページがバッファ プール内にある場合、そのページはバッファ プール内でヒットしたと言われます。ページを直接読んでください。それ以外の場合は、ディスク上のページが読み取られます。データベース内のページの変更操作では、バッファ プール内のページが最初に変更され、次に特定の頻度でディスクに更新されます。ここで注意する必要があるのは、ページをバッファ プールからディスクにフラッシュする操作は、ページが更新されるたびにトリガーされるのではなく、チェックポイントと呼ばれるメカニズムを通じてディスクにフラッシュされることです。これも、データベース全体のパフォーマンスを向上させるためです。
従来の LUR アルゴリズム
バッファ プールは、LRU (最近使用されたもの、最も最近使用されたもの) アルゴリズム、つまり最も頻繁に使用されるアルゴリズムを通じて管理されます。ページ LRU リストの先頭にあり、最も使用されていないページは LRU リストの末尾にあります。バッファ プールが新しく読み取られたページを格納できない場合、LRU リストの末尾にあるページが最初に解放されます:
(1) ページ 既にバッファー プール内にある場合は、LRU ヘッドへの「移動」アクションのみが実行され、ページは削除されません。
(2) ページは削除されません。 LRU ヘッドにページを「置く」アクションを除き、バッファ プールに追加します。アクションだけでなく、LRU テール ページを「削除」することもできます。
ただし、InnoDB の LUR アルゴリズムは、従来の LUR アルゴリズムではありません。
ここには 2 つの問題があります:
(1) 事前読み取りの失敗;
(2) バッファープールの汚染;
まず、事前読み取りとは何かを理解しましょう。 -reading は Read;
先読み
ディスクの読み取りと書き込みはオンデマンドでの読み取りではなく、ページごと (少なくとも 1 ページ) で読み取ります。一度にページデータ (通常は 4K) を取得し、将来読み取られるデータがページ内にある場合、後続のディスク IO を省略でき、効率が向上します。通常、データアクセスは「集中的な読み書き」の原則に従い、あるデータを使用する場合、近くのデータが使用される可能性が高く、早期ロードが有効であることを示す、いわゆる「ローカリティ原理」を示します。実際にディスク IO を削減できます。
先読み失敗
先読み (Read-Ahead) により、ページは事前にバッファ プールに置かれ、しかし、最終的に MySQL は失敗しました。 ページからデータを読み取ることは、先読みエラーと呼ばれます。
先読みの失敗を最適化するためのアイデアは次のとおりです。
(1) 先読みに失敗したページをできるだけ短い時間バッファ プール LRU に留まらせる。
( 2) 実際に読み取られるページをバッファ プール LRU の先頭に移動させます。
は、実際に読み取られるホット データがバッファ プール内にできるだけ長く留まるようにするためです。できるだけ。
具体的な方法は次のとおりです。
(1) LRU を 2 つの部分に分割します。
新世代 (新しいサブリスト)
旧世代 (古いサブリスト) ) )
(2) 新しい世代と古い世代の端は接続されています。つまり、新しい世代の末尾は古い世代の先頭に接続されています。
(3)新しいページ (たとえば、次のように) 先読みページがバッファー プールに追加されると、古い世代の先頭にのみ追加されます:
データが実際に読み取られる場合 (先読みは成功した場合）、新しい世代の先頭に追加されます
データが読み取られていない場合は、新しい世代の「ホット データ ページ」よりも先にバッファ プールから削除されます
新世代および旧世代の LRU の改良版では、バッファ プール汚染の問題は依然として解決できません。
ログ バッファは、REDO ログをキャッシュするために使用されます。
InnoDB には、undo ログと redo ログという 2 つの非常に重要なログがあります。
(1) Undo ログを通じて、以前のバージョンのデータを確認したり、MVCC を実装したり、トランザクションやその他の機能をロールバックしたりできます。
(2) REDO ログを使用してトランザクションの耐久性を確保します。
#REDO ログ バッファは、ディスク上のログ ファイルに書き込まれるデータを保存するために使用されるメモリ記憶領域です。ログ バッファのサイズは innodb_log_buffer_size 変数で定義され、デフォルトのサイズは 16MB です。
ログ バッファの内容は定期的にディスクにフラッシュされます。ログ バッファが大きいと、トランザクションがコミットされる前に REDO ログ データがディスクに書き込まれることなく、大規模なトランザクションを実行できます。したがって、多くの行を更新、挿入、または削除するトランザクションがある場合、ログ バッファー サイズを増やすとディスク I/O を節約できます。
innodb_flush_log_at_trx_commit: ログ バッファーの内容をディスクに書き込み、フラッシュする方法を制御します。
innodb_flush_log_at_timeout: ログの更新頻度を制御します。
多くの BLOB エントリを含むトランザクションなど、ディスク I/O によってパフォーマンスの問題が発生している場合は、トランザクションを観察する必要があります。 InnoDB ログ バッファは満杯になるたびにディスクにフラッシュされるため、バッファ サイズを増やすと I/O が削減される可能性があります。
ログ ファイルのデフォルトの数は、ib_logfile0 と ib_logfile1 の 2 つです。
ログのサイズは固定されており、デフォルトのサイズは MySQL のバージョンによって異なります。
アダプティブ ハッシュ インデックスアダプティブ ハッシュ インデックスは、ホット ページが配置されているレコードを格納するキーと値のペアのストレージ構造です。 InnoDB ストレージ エンジンは、アクセスの頻度とパターンに基づいて、特定のページのハッシュ インデックスを自動的に作成します。
#上の図は、B-tree インデックスとアダプティブ ハッシュ インデックスの違いです。 innodb_adaptive_hash_index パラメータを使用してこの機能を無効または有効にします。このパラメータはデフォルトで有効になっています。
変更バッファ: MySQL のデータはメモリとディスクの 2 つの部分に分割され、ホット データ ページとインデックス ページをバッファ プールにキャッシュしてディスク読み取りを削減し、変更を通じてバッファはディスクへの書き込みを容易にする手段です。
データ ページを更新する必要がある場合、データ ページがメモリ内にある場合は直接更新します。データ ページがメモリ内にない場合。データの一貫性に影響を与えることなく、InooDB はこれらの更新操作を変更バッファーにキャッシュするため、このデータ ページをディスクから読み取る必要はありません。次のクエリでこのデータ ページにアクセスする必要がある場合、データ ページをメモリに読み取り、変更バッファ内のこのページに関連する操作を実行します。このようにして、データロジックの正確性を保証できます。
名前は変更バッファと呼ばれていますが、実際には永続化できるデータです。つまり、変更バッファのコピーはメモリ内にあり、ディスク (ibdata) にも書き込まれます。
変更バッファ内の操作を元のデータ ページにマージし、最新の結果を取得する処理をマージ といいます。次の状況でマージがトリガーされます:
このデータ ページにアクセスします;
バックグラウンド マスター スレッドは定期的にマージされます;
データベース バッファ プールが十分でない場合;
データベースが正常にシャットダウンされた場合;
REDO が実行された場合ログがいっぱいです;
変更バッファとは、非一意の通常のインデックス ページがバッファ プールになく、そのページで書き込み操作が実行されると、レコード変更バッファが最初にバッファリングされ、その後将来のデータが読み取られるときに変更バッファーが変更され、元のデータ ページにマージされる操作のテクノロジが使用されます。 MySQL 5.5 より前は挿入バッファと呼ばれ、挿入のみに最適化されていましたが、現在は削除と更新にも有効であり、書き込みバッファ (変更バッファ) と呼ばれています。
推奨学習: mysql ビデオ チュートリアル
以上がMySQL ストレージ エンジン InnoDB アーキテクチャの詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
