データベース最適化のレビュー (第 2 章)

第 2 章:

ストレージエンジン

MySQL ストレージエンジンは実際には抽象クラスです。ファイルアクセスレイヤーの抽象インターフェイスは、ファイルアクセスメカニズムをカスタマイズするために使用されます。このアクセスメカニズムはストレージエンジンと呼ばれます。MySQL を他のデータベースと区別する最も重要な機能は、プラグインです。ストレージエンジンインターフェイスモジュール、プラガブルストレージエンジン内。

ストレージエンジンは、MySQL 公式ストレージエンジンとサードパーティストレージエンジンに分類できます。

MySQL の公式および最も主流のストレージエンジンには次のものがあります。

MyISAMストレージエンジン
InnoDBストレージエンジン
メモリストレージエンジン
NDBストレージエンジン
アーカイブストレージエンジン

MyISAM ストレージエンジン (OLAP データベースアプリケーション用)

ストレージ制限: 256TB
トランザクションをサポートせず、MVCC (マルチバージョン同時実行制御) をサポートしません。
ロック粒度:テーブルレベル
サポートされているインデックスの種類: B ツリーインデックス、フルテキストインデックス
レプリケーションはサポートされます、外部キーはサポートされません、クエリキャッシュはサポートされます
高速アクセス速度、優れたインデックス最適化およびデータ圧縮テクノロジー

MyISAM ストレージエンジンテーブルは、MYD と MYI で構成されます。MYDはデータファイルの格納に使用され、MYI はインデックスファイルの格納に使用されます。

MySQL 5.0 より前では、MyISAM はデフォルトで 4 GB のテーブルサイズをサポートし、MySQL 5.0 以降では、256 TB の単一テーブルデータをサポートします。

MyISAM バッファプールはインデックスファイルのみをキャッシュし、データファイルはキャッシュしません。

InnoDB ストレージエンジン (OLTP データベースアプリケーション用)

トランザクションのサポート、MVCC (マルチバージョン同時実行制御) のサポート
ロックの粒度:行レベル
サポートされているインデックスタイプ: B ツリーインデックス、アダプティブハッシュインデックス、フルテキストインデックス
レプリケーションのサポート、外部キーのサポート、クエリキャッシュのサポート

MyISAM と InnoDB の違い:

MyISAM はテーブルの合計行数を保存しますが、InnoDB はテーブルの合計行数を保存しません。

MyISAM のクエリ速度は InnoDB よりもはるかに高速です。

NDBストレージエンジン

NDB ストレージエンジンは、クラスタ化されたストレージエンジンです。

NDB の特徴は、すべてのデータがメモリ上に格納されるため、主キーの検索が非常に速く、可用性が高く高性能なクラスタシステムです。

ただし、テーブルの接続操作はストレージエンジン層ではなく、MySQL データベース層で行われます。これは、複雑な接続操作には膨大なネットワークオーバーヘッドが必要なため、複雑なクエリが遅くなり、NDB ストレージエンジンがトランザクションをサポートしないことを意味します。

メモリストレージエンジン

メモリストレージエンジンは、テーブル内のデータをメモリに保存します。データベースが再起動またはクラッシュすると、テーブル内のデータは消えます。

一時データの保存に適した一時テーブル。

メモリストレージエンジンは非常に高速ですが、使用には依然として一定の制限があります。たとえば、テーブルロックのみがサポートされ、同時実行パフォーマンスは低く、トランザクションはサポートされません。メモリストレージエンジンは、デフォルトで B+ ツリーインデックスの代わりにハッシュインデックスを使用します。

アーカイブストレージエンジン

アーカイブストレージエンジンは、INSERT 操作と SELECT 操作のみをサポートします。zlib アルゴリズムを使用してデータ行を圧縮して保存すると、圧縮率は通常 1:10 に達します。

アーカイブストレージエンジンは、ログ情報などのアーカイブデータの保存に非常に適しています。

アーカイブストレージエンジンはトランザクションセーフではなく、その設計目標は主に高速な挿入および圧縮機能を提供することです。

エンジン改造

変換テーブルのストレージエンジンは、元のストレージエンジンに関連するすべての機能を失います。たとえば、InnoDB テーブルを MyISAM に変換してから InnoDB に戻すと、元の InnoDB テーブル上のすべての外部キーが消えます。

Innodb ストレージエンジンのアーキテクチャ

バッファプール
バッファを変更する
適応型ハッシュインデックス
REDOログバッファ
二重書き込み

MySQL は WAL を使用して、データベーストランザクションの一貫性と耐久性を確保します。具体的には：

レコードを変更する前に、必ず最初に。
トランザクションの送信プロセス中、トランザクションの送信が完了するように、ログが最初にディスクに配置されていることを確認する必要があります。

InnoDBバッファプール

InnoDB エンジンはバッファプールテクノロジを使用して、データベースの全体的なパフォーマンス (速度) を向上させます。

InnoDB ストレージエンジンにはさまざまなバッファプールがあります。これらのバッファブロックは、大規模な InnoDB ストレージエンジンメモリプールを形成します。主なタスクは次のとおりです。

すべてのプロセス/スレッドがアクセスする必要がある複数の内部データ構造を維持します。
高速読み取りのためにデータをディスクにキャッシュし、ディスクファイルを変更する前にキャッシュします。
REDOログキャッシュなど

Innodb エンジンのディスクとメモリ間のデータ対話の基本単位はデータページであり、デフォルトのサイズは 16KB です。

Innodb エンジンは、各キャッシュページに対応するブロック構造を作成し、そのブロック構造にはテーブルスペース番号やページのページ番号などの情報が格納されます。

データページは、LRU の最も最近使用されていないアルゴリズムを通じてスワップインおよびスワップアウトされます。

バッファプール関連のパラメータ

innodb_buffer_pool_size : バッファプールの合計サイズ
innodb_buffer_pool_instances : バッファプール内のインスタンスの数同時ロック競合の圧力を軽減するために、バッファプールは複数のインスタンスに分割されます。
innodb_buffer_pool_chunk_size : チャンクのサイズ、デフォルトは 128M Mysql5.7 バージョン以降、Innodb エンジンはチャンク構造を導入しました。バッファプール(拡張時)はオペレーティングシステムからの連続したメモリ空間の一部に適用されます｡チャンク単位でオペレーティングシステムに適用されます｡チャンクにはキャッシュページの制御ブロックやキャッシュページ､リンクリスト情報が格納されます｡これらのキャッシュページを管理します。
innodb_buffer_pool_dump_at_shutdown=ON は、MySQL のシャットダウン時に、メモリ内のホットデータがディスク上の ib_buffer_pool ファイルに保存されることを意味します。
innodb_buffer_pool_load_at_startup=ON は、起動時にホットデータが Buffer_Pool バッファプールに自動的にロードされることを意味します。このようにして、ホットデータは常にメモリ内に保持されます。

InnoDBの変更バッファ

通常、セカンダリインデックスは一意ではなく、挿入順序は非常にランダムで、更新と削除は隣接した位置にありません。変更バッファにより、多数のランダムI/O の生成が回避され、複数の操作が少数の I/O に変換されます。可能な限り /O 操作を行います。

変更バッファの関連パラメータ:

innodb_change_buffering : キャッシュに対応する操作。
innodb_change_buffer_max_size : バッファープール内の変更バッファーの最大パーセンテージを構成するために使用されます。

InnoDB のアダプティブハッシュインデックス

lnnoDB ストレージエンジンは、テーブル上のセカンダリインデックスのルックアップを監視します。セカンダリインデックスへのアクセスが頻繁であることが判明した場合、セカンダリインデックスはホットデータとなり、ハッシュインデックスの確立により速度向上が期待できる場合、ハッシュインデックスが確立されるため、アダプティブ、つまり適応型と呼ばれます。ハッシュインデックス。MySQL は自動的に管理され、人間が介入することはできません。

適応型ハッシュインデックスは、バッファプールの B+Tree を通じて構築されます。

アダプティブハッシュインデックスは lnnoDB バッファプールを占有します。

この機能をオフまたはオンにするには、「set global innodb_adaptive_hash_index off/on」コマンドを使用します。

InnoDBのREDOログバッファ

REDO ログバッファには、REDO ログファイルに書き込まれるデータが保存されます。そのサイズはを介して設定されます。

パラメータ:

innodb_flush_log_at_trx_commit、REDO ログのフラッシュ頻度を制御します (0、1、2、セキュリティは低から高、パフォーマンスは高から低)
innodb_log_buffer_size は、REDO ログバッファのサイズを設定します。

InnoDBの二重書き込み

二重書き込み技術の導入により、データ書き込みの信頼性が向上します。シーケンシャル書き込みはランダム書き込みよりもコストが低くなります。欠点は、新しいタイプの SSD ストレージに繰り返し書き込みを行うと、SSD の寿命に大きな影響を与えることです。

パラメータ:

innodb_doublewrite=0 : 二重書き込み機能をオフにする

トランザクションのコミット

トランザクションのコミット処理

ストレージエンジンがトランザクションを実装する一般的な方法は、REDO ログと UNDO ログに基づいています。REDO ログにはトランザクションによって変更されたデータが記録され、Undo ログにはトランザクション前の元のデータが記録されます。

トランザクションが実行されるときに発生する実際のプロセス

まず元に戻す/やり直しログを記録し、ログが永続的なストレージとしてディスクにフラッシュされることを確認します。
データレコードを更新し、操作をキャッシュし、ディスクを非同期的にフラッシュします。
トランザクションログを binlog に保存します。
トランザクションをコミットし、REDO ログにコミットレコードを書き込みます。

binlog はトランザクションストレージエンジンの範囲内にないため、トランザクションがコミットされる前 (更新後、コミット前) にトランザクションログを binlog に保存する必要があります。

トランザクションが送信された後

1. トランザクションが送信された後、元に戻すセグメントがパージされます。パージの主な機能は、実際に物理レコードを削除することです。(削除または更新操作が実行されるとき、実際の古いレコードは実際には削除されません(is_deleted と同様)。レコードにはマークが付けられますが、トランザクションがコミットされた後、パージスレッドによって実際にレコードが削除されます。)

2.リソースのロックを解除する

3. REDO ログをブラシします。REDO ログの削除操作を通じてデータベースの整合性と一貫性を確保します。

4.セーブポイントリストをクリーンアップします。実際には、各ステートメントにはロールバック用のセーブポイントがあります。

InnoDB バックグラウンドスレッド

InnoDB バックグラウンドスレッドの主な機能は、メモリプール内のデータを更新して、バッファプール内のメモリキャッシュが最新のデータであることを確認することです。

InnoDB メインスレッド

マスタースレッド:主なジョブは、ダーティページのリフレッシュ、バッファのマージと挿入などを含む、バッファプール内のデータをディスクに非同期にリフレッシュしてデータの整合性を確保することです。

マスタースレッドは最も高いスレッド優先度を持ち、その内部は複数のループで構成されます。マスタースレッドは、データ操作の状態に応じて数サイクル間で切り替わります。

バックグラウンドループ
1. 無駄なUndoページを削除（常に）
2. 一定量の挿入バッファーをマージします (常に)
3. ユーザーアクティビティがある場合はメインループに戻り、そうでない場合は更新ループにジャンプします (常に)
リフレッシュサイクル
1. 一定数のダーティページをディスクにフラッシュします (常に)
2. 一時停止ループにジャンプします (常に)
一時停止ループ
1. マスタースレッドを一時停止する
2. イベントが発生すると、メインループにジャンプします (常に)

InnoDB バックグラウンド I/O スレッド

AIO非同期 I/O は、 I/O リクエストを処理するためにInnoDB ストレージエンジンで広く使用されており、データベースのパフォーマンスを大幅に向上させることができます。

読み取りスレッドは、ディスクからバッファプールのページにデータをロードする役割を果たします。

書き込みスレッドは、バッファプールのダーティページをディスクにフラッシュする役割を果たします。

ログスレッドは、ログバッファの内容をディスクにフラッシュする役割を果たします。

挿入バッファスレッドは、変更バッファの内容をディスクにフラッシュする役割を果たします。

パラメータ: 構成ファイル my.cnf で設定できます。

innodb_read_io_threads
Innodb_write_io_threads

InnoDB ダーティページリフレッシュスレッド

MySQL 5.6 より前では、ダーティページのクリーニングはマスタースレッドによって処理されていました。5.6 以降、ページクリーナースレッドは、バッファプール内のダーティページをフラッシュする作業を実装します。

パラメータ:

innodb_page_cleaners : ダーティページフラッシュスレッドの数を設定します。(複数ページクリーナースレッドはバージョン 5.7.4 以降に導入されました)
Innodb_buffer_pool_wait_free : ダーティページがシステムのパフォーマンスのボトルネックになっているかどうかをマークします。innodb_buffer_pool_size が十分に大きい場合は、Innodb_buffer_pool_wait_free の値を小さくすることも、0 にすることもできます。

InnoDB パージスレッド

パージスレッドは、使用され割り当てられた (元のデータの記録) アンドゥページを再利用する責任があります。

例外：

挿入操作はこのトランザクションのみに表示され、トランザクションがコミットされた直後に削除されるため、挿入取り消しログはパージする必要がありません。
更新取り消しログは更新削除操作によって生成され、後で MVCC によって使用される可能性があるため、送信時に削除することはできません。これはアンドゥログのリンクリストに追加され、最終的に削除されるパージを待ちます。

データ行を削除および更新する場合、データページで削除されるデータ行を「削除済み」としてマークすると、トランザクションの送信速度が速くなります。バックグラウンドスレッドのパージスレッドが、データ内の「削除済み」ラベルが付いたデータ行を実際に削除します。ページ。

パラメータ:

innodb_purge_threads : 同時パージスレッドの数を調整できます。