InnoDB 行ストレージ形式とは何ですか-mysql チュートリアル-php.cn

以前の InnoDB バージョンでは、ファイル形式が 1 つしかなかったため、このファイル形式に名前を付ける必要はありませんでした。 InnoDB エンジンが進化するにつれて、新機能をサポートするために、以前のバージョンと互換性のない新しいファイル形式が開発されています。今日は InnoDB の行ストレージ形式を紹介します。

InnoDB 行ストレージ形式とは何ですか

InnoDB ストレージエンジンは、REDUNDANT、COMPACT、DYNAMIC、COMPRESSED の 4 つの形式をサポートします。

#InnoDB 行形式の概要

InnoDB 行ストレージ形式とは何ですか

##REDUNDANT 行形式 #REDUNDANT 形式は、古いバージョンの MySQL との互換性を提供します。 REDUNDANT 行形式は、2 つの InnoDB ファイル形式 (Antelope と Barracuda) でサポートされています。

REDUNDANT 行形式を使用するテーブルは、可変長列値 (VARCHAR、VARBINARY、BLOB および TEXT 型) の最初の 768 バイトを B ツリーノード内のインデックスレコードに格納し、残りをオーバーフローに格納します。ページ。 768 バイト以上の固定長列は可変長列としてエンコードされ、オフページに格納できます。たとえば、文字セットの最大バイト長が 3 utf8mb4 より大きい場合、CHAR(255) 列は 768 バイトを超える可能性があります。

列の値が 768 バイト以下の場合、オーバーフローページは使用されず、値が完全に B ツリーノードに格納されるため、I/O がいくらか節約される可能性があります。これは、比較的短い BLOB 列値の場合は正常に機能しますが、B ツリーノードにキー値ではなくデータが設定され、効率が低下する可能性があります。多くの BLOB 列を含むテーブルでは、B ツリーノードがいっぱいになり、含まれる行が少なすぎるため、行が短い場合や列値がオフページに格納されている場合よりもインデックス全体の効率が低下する可能性があります。

#REDUNDANT 行フォーマットのストレージ特性

REDUNDANT 行フォーマットには次のストレージ特性があります。

各インデックスレコードには 6 つのインデックスレコードが含まれます。バイトヘッダー。ヘッダーは、連続するレコードをリンクしたり、行レベルのロックに使用されます。

クラスター化インデックスのレコードには、すべてのユーザー定義列のフィールドが含まれます。さらに、6 バイトのトランザクション ID フィールドと 7 バイトのローリングポインターフィールドがあります。
テーブルに主キーが定義されていない場合、各クラスター化インデックスレコードには 6 バイトの行 ID フィールドも含まれます。
各セカンダリインデックスレコードには、セカンダリインデックスにないクラスター化インデックスキーに対して定義されたすべての主キー列が含まれています。
レコードには、レコードの各フィールドへのポインターが含まれています。レコード内のフィールドの合計長が 128 バイト未満の場合、ポインターは 1 バイト、それ以外の場合は 2 バイトになります。ポインタの配列はレコードディレクトリと呼ばれます。ポインタが指す領域がレコードのデータ部分です。
内部的には、CHAR(10) などの固定長の文字列は固定長形式で格納されます。 VARCHAR 列の末尾のスペースは切り捨てられません。 768 バイト以上の固定長列は可変長列としてエンコードされ、オフページに格納できます。たとえば、文字セットの最大バイト長が 3 utf8mb4 より大きい場合、CHAR(255) 列は 768 バイトを超える可能性があります。
SQL NULL 値は、レコードディレクトリに 1 バイトまたは 2 バイトを保持します。 NULL SQL 値は、可変長列に格納される場合、レコードのデータ部分にゼロバイトを保持します。固定長列の場合、列の固定長はレコードのデータ部分に保持されます。 NULL 値用の固定スペースを予約すると、インデックスページの断片化を引き起こすことなく列を NULL から非 NULL 値に更新できます。
#COMPACT 行フォーマット

COMPACT 行フォーマットは、REDUNDANT 行フォーマットと比較して行数を約 20% 削減します。記憶域スペース (冗長性) を使用すると、特定の操作での CPU 使用率が増加します。ワークロードが標準的で、キャッシュヒット率とディスク速度によって制限されている場合は、COMPACT 形式の方が高速である可能性があります。ワークロードが CPU 速度によって制限されている場合、コンパクト形式は遅くなる可能性があります。 COMPACT 行形式は、2 つの InnoDB ファイル形式 (Antelope と Barracuda) でサポートされています。 COMPACT 行形式を使用するテーブルは、可変長列値 (VARCHAR、VARBINARY、BLOB および TEXT 型) の最初の 768 バイトを B ツリーノード内のインデックスレコードに格納し、残りをオーバーフローに格納します。ページ。

768 バイト以上の固定長列は可変長列としてエンコードされ、オフページに格納できます。たとえば、文字セットの最大バイト長が 3 より大きい場合、CHAR(255) は、列が utf8mb4 文字型の場合、768 バイトを超える可能性があります。

COMPACT 行形式のストレージプロパティ

COMPACT 行形式には、次のストレージ特性があります。

各インデックスレコードには 5 バイトのヘッダーが含まれており、その前に可変長ヘッダーを付けることができます。。ヘッダーは、連続するレコードをリンクしたり、行レベルのロックに使用されます。
レコードヘッダーの可変長部分には、NULL 列を示すビットベクトルが含まれています。インデックス内の列の数が NULL になる可能性がある場合、ビットベクトルは N バイトを占有します。 (たとえば、9 ～ 16 列が存在する可能性がある場合、ビットベクトルは 2 バイトを使用します。) このベクトル内のビットを超える領域を占有しない列。ヘッダーの可変長部分には、可変長列の長さも含まれます。列の最大長に応じて、各長に 1 バイトまたは 2 バイトが必要です。インデックス内のすべての列が CEILING(*N*/8)NULLNULLNOT NULL で固定長の場合、レコードヘッダーには可変長部分がありません。
NULL 以外の可変長フィールドごとに、レコードヘッダーには列の長さの 1 バイトまたは 2 バイトが含まれます。列の一部がオーバーフローページの外側に格納されている場合、または最大長が 255 バイトを超え、実際の長さが 127 バイトを超えている場合、必要なのは 2 バイトだけです。外部ストレージ列の場合、2 バイトの長さは、内部ストレージセクションの長さに、外部ストレージセクションへの 20 バイトのポインタを加えたものを表します。内側の部分は 768 バイトなので、長さは 768 20 です。20 バイトのポインターには、列の実際の長さが格納されます。
レコードヘッダーの後には、NULL 以外の列のデータ内容が続きます。
クラスター化インデックスのレコードには、すべてのユーザー定義列のフィールドが含まれます。さらに、6 バイトのトランザクション ID フィールドと 7 バイトのローリングポインターフィールドがあります。
テーブルに主キーが定義されていない場合、各クラスター化インデックスレコードには 6 バイトの行 ID フィールドも含まれます。
各セカンダリインデックスレコードには、セカンダリインデックスにないクラスター化インデックスキーに対して定義されたすべての主キー列が含まれています。主キー列が可変長の場合、セカンダリインデックスが固定長列に定義されている場合でも、各セカンダリインデックスのレコードヘッダーにはその長さを記録する可変長セクションがあります。
内部的には、非可変長文字セットの場合、固定長文字シーケンス (例: CHAR(10) 固定長形式で格納)。 VARCHAR 列の末尾のスペースは切り捨てられません。
内部的には、utf8mb3 や utf8mb4 などの可変長文字セットの場合、InnoDB は末尾のスペースをトリミングしてバイトを格納しようとします。列値がバイトを超える場合、末尾のスペースは列値の最小長 (バイト単位) に調整されます。列の最大長は、最大文字バイト長 × CHAR(*N*)NCHAR(*N*)NCHAR(*N*)

N は最小バイト数を保持します。。多くの場合、最小限のスペースを確保すると、インデックスページの断片化を引き起こすことなく列の更新を完了できます。対照的に、行形式を使用する場合、列は最大文字バイト長 × CHAR(*N*)NCHAR(*N*)NREDUNDANT

を占有し、768 バイト以上の固定長列はエンコードされます。可変長フィールドであり、オフページに保存できます。たとえば、文字セットの最大バイト長が 3 より大きい場合、CHAR(255) は、列が utf8mb4 文字型の場合、768 バイトを超える可能性があります。

#COMPACT 行フォーマットのストレージ特性図

MySQL InnoDB COMPAT 行フォーマット構造

InnoDB 行ストレージ形式とは何ですか #MySQL InnoDB COMPAT 行フォーマット構造ヘッダー情報

#MySQL InnoDB COMPAT 行フォーマット構造ヘッダー情報の説明 InnoDB 行ストレージ形式とは何ですか | 名前| サイズ (ビット) | 説明| | ———— | ——— | — ——————————————————— | | 予約ビット | 1 | 不明 | | 予約ビット | 1 | 不明 | | delete_flag | 1 | 行が削除されたかどうか | | min_rec_flag | 1 | レコードが最小レコードとして事前定義されている場合は 1 | | n_owned | 4 | このレコードが所有するレコードの数 | | heap_no | 13 | インデックスヒープ内のこのレコードのソートされたレコード | | Record_type | 3 | Recordタイプ、000 は通常を意味します、001 は B ツリーノードポインターを意味します、010 は無限を意味します、011 はスーパーマムを意味します、1xx は予約を意味します | | next_record | 16 | ページ内の次のレコードの相対位置

実際には、InnoDB各データに 3 つの非表示列が追加されます。これらは

InnoDB 行ストレージ形式とは何ですか ##DYNAMIC 行形式

DYNAMIC です。 row 形式は COMPACT 行形式と同じストレージ機能を提供しますが、長い可変長列に対する拡張ストレージ機能と、大きなインデックスキープレフィックスのサポートが追加されています。 Barracuda ファイル形式は DYNAMIC ライン形式をサポートしています。

ROW_FORMAT=DYNAMIC を使用する場合はテーブルを作成します。InnoDB は、長い可変長カラム値を完全にオフページに格納できます (VARCHAR、VARBINARY、BLOB、および TEXT タイプの場合)。クラスター化インデックスレコードには、オーバーフローページのセクションポインター。 768 バイト以上の固定長フィールドは、可変長フィールドとしてエンコードされます。たとえば、文字セットの最大バイト長が 3 より大きい場合、CHAR(255) は、列が utf8mb4 文字型の場合、768 バイトを超える可能性があります。

列がオフページに格納されるかどうかは、ページサイズと行の合計サイズによって異なります。行が長すぎる場合は、クラスター化インデックスレコードが B ツリーページに収まるまで、最長の列がオフページストレージとして選択されます。 TEXT および BLOB は、ライン上に格納される 40 バイト以下の列です。

DYNAMIC 行形式は、(COMPACT 形式と REDUNDANT 形式で行われるように) インデックスノードに行全体を格納する効率を維持しますが、DYNAMIC 行形式では、B ツリーノードが大きなデータで埋め尽くされるのを回避します。長い列データのバイト数が問題です。 DYNAMIC 行形式は、長いデータ値の一部がページ外に格納される場合、通常は値全体をページ外に格納するのが最も効率的であるという考えに基づいています。 DYNAMIC 形式の場合、B ツリーノードに短い列が保持されるため、特定の行に必要なオーバーフローページの数が最小限に抑えられます。

DYNAMIC 行形式は、最大 3072 バイトのインデックスキープレフィックスをサポートします。この機能は、デフォルトで有効になっている innodb_large_prefix 変数によって制御されます。 innodb_large_prefix の詳細については、変数の説明を参照してください。

DYNAMIC 行フォーマットを使用する表は、システム表スペース、表ごとのファイル表スペース、および一般表スペースに保管できます。システムテーブルスペースにテーブルを動的に保存するには、innodb_file_per_table を無効にして通常の CREATE TABLE または ALTER TABLE ステートメントを使用するか、CREATE TABLE または ALTER TABLE で TABLESPACE [=] innodb_system テーブルオプションを使用します。 innodb_file_per_table 変数と innodb_file_format 変数は、一般的なテーブルスペースには適用されません。また、システムテーブルスペースに DYNAMIC テーブルを格納するために TABLESPACE [=] innodb_system テーブルオプションが使用されている場合にも適用されません。

#DYNAMIC 行フォーマットの記憶域プロパティ

DYNAMIC 行フォーマットは COMPACT 行フォーマットとは異なります。

COMPRESSED 行形式

COMPRESSED 行形式は、DYNAMIC 行形式と同じストレージ機能と機能を提供しますが、テーブルと機能が追加されています。インデックスデータ圧縮のサポート。

Barracuda ファイル形式は COMPRESSED 行形式をサポートしています。

COMPRESSED 行形式は、DYNAMIC 行形式と同様の内部詳細のオフページストレージを使用します。これにより、テーブルとインデックスデータの追加のストレージとパフォーマンスの考慮事項が圧縮され、より小さいページサイズが使用されます。 COMPRESSED 行形式を使用する場合、KEY_BLOCK_SIZE オプションは、クラスター化インデックスに格納される列データの量と、オーバーフローページに配置される列データの量を制御します。

COMPRESSED 行形式は、最大 3072 バイトのインデックスキープレフィックスをサポートします。この機能は、デフォルトで有効になっている innodb_large_prefix 変数によって制御されます。

COMPRESSED 行形式を使用するテーブルは、ファイルテーブルスペースまたはテーブルごとの一般テーブルスペースに作成できます。システム表領域は COMPRESSED 行形式をサポートしていません。 COMPRESSED テーブルを file-per-table テーブルスペースに保存するには、innodb_file_per_table 変数を有効にし、innodb_file_format を Barracuda に設定する必要があります。 innodb_file_per_table 変数と innodb_file_format 変数は、一般的なテーブルスペースには適用されません。一般表スペースはすべての行フォーマットをサポートしますが、物理ページ・サイズが異なるため、圧縮表と非圧縮表は同じ一般表スペース内に共存できないことに注意してください。詳細は、「一般的なテーブルスペース」を参照してください。

COMPRESSED 行フォーマットの記憶域プロパティ

COMPRESSED 行フォーマットは COMPACT 行フォーマットとは異なります。行オーバーフローデータを処理する場合は少し異なります。文字列の最初の 768 バイトは、記録された実際のデータには保存されません。代わりに、すべてのバイトは、記録された実際のデータにのみ他のページに保存されます。他のページのアドレスはここに保存されます。さらに、圧縮行形式では、圧縮アルゴリズムを使用してページを圧縮します。