17.11.2 File Space Management
Tablespcae
- Tablespcae は
ibdata1、ibdata2などの物理ファイルで構成される。 - 各テーブルスペースは、データベースページで構成される。
-- Aurora 初期構築時
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_DATAFILES;
+------------------------+-------------------------------------------+
| SPACE | PATH |
+------------------------+-------------------------------------------+
| 0x30 | ibdata1 |
| 0x34323934393637323739 | ./undo_001 |
| 0x34323934393637323738 | ./undo_002 |
| 0x31 | ./sys/sys_config.ibd |
| 0x33 | ./mysql/rds_configuration.ibd |
| 0x3133 | ./mysql/rds_global_status_history.ibd |
| 0x3134 | ./mysql/rds_global_status_history_old.ibd |
| 0x3135 | ./mysql/rds_heartbeat2.ibd |
| 0x3137 | ./mysql/rds_sysinfo.ibd |
| 0x34323934393637323737 | ./undo_003 |
| 0x3138 | ./mysql/aurora_s3_load_history.ibd |
| 0x3230 | ./mysql/ro_replica_status_internal.ibd |
| 0x3235 | ./mysql/rds_history.ibd |
| 0x3236 | ./mysql/rds_replication_status.ibd |
+------------------------+-------------------------------------------Page
- ページとは
InnoDBがディスク (データファイル) とメモリー (バッファプール) の間で一度に転送するデータ量を表す単位。 ページには 1 つ以上の行を含めることができます (各行のデータ量に依存)。 行全体が単一ページに収まらない場合、InnoDBでは、行に関する情報を単一ページに格納できるようにポインタスタイルの追加データ構造が設定されます。- innodb_page_size オプションでページサイズを指定
- 各ページにより多くのデータを収める方法の 1 つは、圧縮行フォーマットを使用ことです。 BLOB またはラージテキストフィールドを使用するテーブルの場合、コンパクト行フォーマットを使用してこれらのラージカラムを残りの行とは別個に格納することで、これらのカラムを参照しないクエリーの I/O オーバーヘッドとメモリー使用量を減らすことができます。
InnoDBは、I/O スループットを向上させるために一連のページをバッチとして読み書きするときに、extent を一度に読み書きします。- MySQL インスタンス内のすべての
InnoDBディスクデータ構造は、同じページサイズを共有します。
The basics of InnoDB space file layout
各ページには38バイトのFILヘッダと8バイトのFILトレーラ（FILは「file」の略称）があります。
ヘッダにはページタイプを示すフィールドがあり、これによってページの残りの構造が決まります。
FILヘッダとトレーラの構造は以下の通りです。
- FILヘッダ（38バイト）
各ページの先頭にあり、ページの種類や状態を表す情報が含まれます。 - FILトレーラ（8バイト）
ページの最後にあり、ページの整合性チェックなどに使われる情報が含まれます。 - ページタイプ
ヘッダ内の「ページタイプ」フィールドによって、そのページがどのような役割を持つか（例：インデックスページ、データページなど）が決まります。 - ページは、最大 16K バイトのサイズ (16K バイトの連続した 64 ページ) でサイズ 1M バイトの extents にグループ化されます。
Extent
- エクステントとは
-- Aurora 初期構築時
-- Extent の概算見積もり
SELECT
NAME,
FILE_SIZE,
ALLOCATED_SIZE,
FLOOR(ALLOCATED_SIZE / (1024 * 1024)) AS extent_count_approx
FROM
INFORMATION_SCHEMA.INNODB_TABLESPACES;
+-------------------------------------+-----------+----------------+---------------------+
| NAME | FILE_SIZE | ALLOCATED_SIZE | extent_count_approx |
+-------------------------------------+-----------+----------------+---------------------+
| mysql | 46137344 | 46137344 | 44 |
| innodb_temporary | 12582912 | 12582912 | 12 |
| innodb_undo_001 | 16777216 | 16777216 | 16 |
| innodb_undo_002 | 16777216 | 16777216 | 16 |
| sys/sys_config | 4194304 | 4194304 | 4 |
| mysql/rds_configuration | 4194304 | 4194304 | 4 |
| mysql/rds_global_status_history | 4194304 | 4194304 | 4 |
| mysql/rds_global_status_history_old | 4194304 | 4194304 | 4 |
| mysql/rds_heartbeat2 | 4194304 | 4194304 | 4 |
| mysql/rds_sysinfo | 4194304 | 4194304 | 4 |
| innodb_undo_003 | 16777216 | 16777216 | 16 |
| mysql/aurora_s3_load_history | 4194304 | 4194304 | 4 |
| mysql/ro_replica_status_internal | 4194304 | 4194304 | 4 |
| mysql/rds_history | 4194304 | 4194304 | 4 |
| mysql/rds_replication_status | 4194304 | 4194304 | 4 |
+-------------------------------------+-----------+----------------+---------------------+
15 rows in set (0.022 sec)
Segment
-
InnoDBでは、テーブルスペース内部の「ファイル」をセグメントと呼びます。InnoDBテーブルスペース内のディビジョン。 テーブルスペースをディレクトリに例えると、セグメントはそのディレクトリ内のファイルに似ています。 セグメントは増えることができます。 新しいセグメントを作成できます。- たとえば、file-per-table テーブルスペース内では、テーブルデータは 1 つのセグメントにあり、関連付けられた各インデックスは独自のセグメントにあります。 システムテーブルスペースは、多くのテーブルとそれらに関連付けられたインデックスを保持できるため、多くの異なるセグメントを含みます。 MySQL 8.0 より前のシステムテーブルスペースには、undo ログに使用される 1 つ以上のロールバックセグメントも含まれていました。
- セグメントは、データの挿入と削除に応じて拡大、縮小します。 セグメントがより多くの領域を必要とする場合、一度に 1 エクステント (1M バイト) ずつ拡張されます。 同様に、セグメントは、あるエクステント内のすべてのデータが不要になると、そのエクステント分の領域を解放します。
- エクステント, file-per-table, ロールバックセグメント, システムテーブルスペース, テーブルスペース, Undo ログも参照
- セグメントがテーブルスペース内部で拡張される場合、
InnoDBは、そのセグメントに最初の 32 ページを一度に割り当てます。 そのあと、InnoDBは、そのセグメントへのすべてのエクステントの割り当てを開始します。InnoDBは、データの良好な連続性を保証するために、大きなセグメントには 1 回につき最大 4 つのエクステントを追加できます。 InnoDBでは、各インデックスに 2 つのセグメントが割り当てられます。 一方は B-tree の非リーフノード用で、もう一方はリーフノード用です。 リーフノードをディスク上で連続した状態に維持すると、これらのリーフノードには実際のテーブルデータが含まれているため、シーケンシャル I/O 操作の性能が向上します。- テーブルスペース内の一部のページにはほかのページのビットマップが含まれているため、
InnoDBテーブルスペース内のいくつかのエクステントは全体としてではなく、個々のページとしてのみセグメントに割り当てることができます。 SHOW TABLE STATUSステートメントを発行することによってテーブルスペース内の使用可能な空き領域を求めると、InnoDBは、テーブルスペース内の確実に空いているエクステントをレポートします。InnoDBは、常にいくつかのエクステントをクリーンアップやその他の内部の目的のために予約します。これらの予約されたエクステントは空き領域に含まれません。- テーブルからデータを削除すると、
InnoDBは、対応する B ツリーインデックスを短くします。 解放された領域をほかのユーザーが使用できるようになるかどうかは、削除のパターンがテーブルスペースに対して個々のページまたはエクステントのどちらを解放するかによって異なります。 テーブルを削除したりテーブルのすべての行を削除したりすると、その領域は確実にほかのユーザーに解放されますが、それらの削除された行は、それの行がトランザクションロールバックまたは一貫性読み取りに必要なくなったあと、しばらくして自動的に発生するパージ操作によってのみ物理的に削除されることに注意してください。 (セクション15.3「InnoDB マルチバージョン」を参照してください。)
ページのテーブル行への関連付け
行の最大長は、4KB、8KB、16KB および 32KB の innodb_page_size 設定のデータベースページの半分未満です。 たとえば、デフォルトの 16KB の InnoDB ページサイズでは、行の最大長は 8KB 未満です。
行が最大行長を超えない場合、すべての行はページ内にローカルに格納されます。 行が最大行長を超えると、行が最大行長制限内に収まるまで、外部オフページストレージ用に variable-length columns が選択されます。 可変長カラムの外部オフページストレージは、行形式によって異なります:
- COMPACT および REDUNDANT 行フォーマット可変長カラムが外部オフページストレージに選択されると、
InnoDBでは最初の 768 バイトが行にローカルに格納され、残りはオーバーフローページに外部的に格納されます。 このような各カラムには、オーバーフローページの独自のリストがあります。 768 バイトのプリフィクスには、そのカラムの実際の長さを格納し、値の残りの部分が格納されているオーバーフローページリストを指す 20 バイトの値が付随します。 セクション15.10「InnoDB の行フォーマット」を参照してください。 - DYNAMIC および COMPRESSED 行フォーマット可変長カラムが外部オフページストレージに選択されると、
InnoDBでは 20 バイトのポインタが行にローカルに格納され、残りはオーバーフローページに外部的に格納されます。 セクション15.10「InnoDB の行フォーマット」を参照してください。
LONGBLOB および LONGTEXT カラムは 4G バイト未満である必要があり、BLOB および TEXT カラムを含む行全体の長さは 4G バイト未満である必要があります。
Next Action
以下を丸々翻訳して理解してみる
その上で、上でよくわからなかった機能について記載する
コメント