序文
これまでの内容で、テーブル スペースが抽象的な概念であることは誰もが理解していると思いますが、システム テーブル スペースの場合は一个或多个ファイル システム内の実際のファイルに対応し、各独立テーブル スペースの場合はファイル内で一个指定されたテーブルに対応します。 system..ibd実際のファイルの名前。
テーブルスペースは多数のページに分割されたプールと考えることができ、あるテーブルにレコードを挿入したい場合は、プールから対応するページを取り出し、そこにデータを書き込みます。
この章の内容は、テーブル スペースの詳細を深く掘り下げ、InnoDB ストレージ構造のプール内を泳ぐように導きます。この章にはさらに多くの概念が含まれるため、これらの概念は難しいものではありませんが、相互に依存しているため、以下を読むことをお勧めします。不要跳着看
1. 古い知識を思い出してください
1.1 ページの種類
ここでもう一度強調しておきますが、InnoDB はストレージ スペースを単位で管理し页ます。クラスター化インデックス (つまり、完全なテーブル データ) とその他のセカンダリ インデックスは、B+ ツリーの形式でテーブル スペースに保存され、B+ ツリーのノードはデータです。ページ。前に述べたように、このデータ ページのタイプ名は実際には次のとおりですfil_page_index。インデックス データを保存するためのこのページ タイプに加えて、InnoDB ではさまざまな目的に応じていくつかの異なるタイプのページも設計されています。次の表に精通している必要があると思います。
| 型名 | 16進数 | 説明 |
|---|---|---|
| fil_page_type_allocated | 0x0000 | 最新の割り当て、まだ使用されていない |
| fil_page_undo_log | 0x0002 | 元に戻すログページ |
| fil_page_inode | 0x0003 | セグメント情報ノード |
| fil_page_ibuf_free_list | 0x0004 | バッファ空きリストを挿入 |
| file_page_ibuf_bitmap | 0x0005 | バッファビットマップを挿入 |
| fil_page_type_sys | 0x0006 | システムページ |
| fil_page_type_trx_sys | 0x0007 | トランザクションシステムデータ |
| fil_page_type_fsp_hdr | 0x0008 | テーブルスペースのヘッダー情報 |
| fil_page_type_xdes | 0x0009 | 拡張説明ページ |
| fil_page_type_blob | 0x000a | オーバーフローページ |
| fil_page_index | 0x45bf | インデックス ページ (データ ページとも呼ばれます) |
fil_pageページ タイプの前にまたは というプレフィックスがあるためfil_page_type、簡単にするために、後でページ タイプを説明するときにこれらのプレフィックスを省略します。たとえば、fil_page_type_allocatedタイプはallocatedタイプと呼ばれ、fil_page_indexタイプはindexタイプと呼ばれます。等
1.2 ページの共通部分
MySQL之数据页结构前回の記事で、データ ページ、つまりタイプ ページは 7 つの部分で構成され、そのうちの 2 つはすべてのタイプのページに共通であると述べました(indexもちろん、私が言ったことを覚えておいてほしいとは思いませんが、もう一度言います)ここ) どのタイプのページでも、次の一般的な構造があります。
上の画像からわかるように、どのタイプのページにも次の 2 つのセクションが含まれます。
File Header：レコードページに関する一般的な情報File Trailer：ページの整合性を検証して、メモリからディスクに更新されるときのコンテンツの一貫性を確保します。
File Trailer強調しすぎないように、File Headerここでさまざまなコンポーネントをもう一度強調します。
| 名前 | サイズ（単位：B） | 説明 |
|---|---|---|
| fil_page_space_or_chksum | 4 | ページチェックサム（チェックサム値） |
| fil_page_offset | 4 | ページ番号 |
| file_page_prev | 4 | 前のページのページ番号 |
| fil_page_next | 4 | 次のページのページ番号 |
| fil_page_lsn | 8 | ページが最後に変更されたときの対応するログ シーケンスの位置 (英語名は: ログ シーケンス番号) |
| fil_page_type | 2 | ページの種類 |
| fil_page_file_flush_lsn | 8 | これは、システム表スペースの 1 ページでのみ定義されます。これは、ファイルが少なくとも対応する lsn 値までリフレッシュされていることを意味します。 |
| fil_page_arch_log_no_or_space_id | 4 | ページがどの表領域に属しているか |
名前に LSN が含まれている理解できない 2 つのフィールドを除いて、他のフィールドはよく知られているはずですが、それでも次の点を強調しておきます。
-
表スペースの各ページはページ番号に対応します。つまり、
fil_page_offsetページ番号は 4 バイト、つまり 32 ビットで構成されます。そのため、ページの2³²デフォルトのサイズが 16kb である場合、表スペースには最大ページ数を含めることができます。64tb表スペースでサポートされる最大データです。表スペースの最初のページのページ番号は 0 で、後続のページ番号は 1、2、3... というようになります。 -
fil_page_prev一部の種類のページはリンク リストを形成でき、リンク リスト内のページは物理的な順序で保存することはできませんが、合計に従って前のページと次のページのページ番号を保存しますfil_page_next。これら 2 つのフィールドは主にページのタイプ用であることに注意してくださいindex、つまり、これまで説明してきたデータ ページは、B+ ツリーが確立された後にノードの各層の二重リンク リストを確立するために使用されます。のページでは、これら 2 つのフィールドが使用されていません。 -
各ページのタイプは
fil_page_type、たとえば、データ ページのこのフィールドの値によって示されます0x45bf。後でさまざまなタイプのページを紹介しますが、異なるタイプのページでは、このフィールドの値も異なります。
2つの独立したテーブルスペース
InnoDB が多くの種類のテーブル スペースをサポートしていることはわかっており、この記事では独立表空间との構造に焦点を当てます系统表空间。これらの構造は比較的似ていますが、システム表領域にはシステム全体に関する追加情報が含まれているため、最初により単純な独立表領域を紹介し、システム表領域の構造については後ほど説明します。
2.1 エクステントの概念
テーブルスペース内のページが多すぎるため、为了更好的管理这些页面InnoDB ではextentエリア (英語名: ) という概念が提案されています。16KB ページの場合、連続した64ページが 1 つのエリアになります。つまり、1 つのエリアがデフォルトの1MBスペース サイズを占有します。システム表スペースであっても、独立表スペースであっても、複数の領域から構成されているとみなすことができます每256个区被划分成一组。次のようなものであることを示す図を描きます。
その中で、extent 0 ~ extent 255これらの 256 地区がカウントされ第一个组、extent 256 ~ extent 511これらの 256 地区がカウントされ第二个组、extent 512 ~ extent 767これらの 256 地区がカウントされます第三个组(上の図は 3 番目のグループのすべての地区を描いているわけではありません。ご自身で判断してください) など、さらに多くのグループが追加されます。分けられる。これらのグループの最初の数ページは、タイプがすべて似ています。次に例を示します。
上の図から次の情報がわかります。
-
第一个组最开始的3个页面的类型是固定的つまり、エクステント 0 領域の最初の 3 ページのタイプは固定されており、次のとおりです。FSP_HDR类型：このタイプのページは、表空间的一些整体属性以及本组所有的区エクステント 0 ～ エクステント 255 の 256 エリア全体のプロパティを登録するために使用されます。注意すべき点の 1 つは、表領域全体のみが使用可能であるということです一个FSP_HDR类型的页面。IBUF_BITMAP类型：このタイプのページには本组所有的区的所有页面关于INSERT BUFFER情報が保存されます。INODE类型：このタイプのページには、 と呼ばれる多数のINODEデータ構造が保存されます。
-
残りの
最开始的2个页面的类型是固定グループ、つまりエクステント 256 とエクステント 512 の最初の 2 ページのタイプはそれぞれ固定されています。XDES类型：完全な名前はエクステント記述子です。用来登记本组256个区的属性つまり、エクステント 256 にあるこのタイプのページの場合、これらの領域の属性はエクステント 256 ～ エクステント 511 に格納され、エクステント 512 にあるこのタイプのページの場合は、エクステント 512 に格納されます。これらのエリアの 512 ～ 767 件のプロパティ。上記で紹介した FSP_HDR タイプのページは、実際には XDES タイプのページと似ていますが、FSP_HDR タイプのページにはいくつかの表スペース属性が追加で格納される点が異なります。IBUF_BITMAP类型：上記と同様なので、これ以上の説明は省略します。
マクロの構造は次のようなもので、中の名詞はあまり明確に覚える必要はなく、大まかに覚えていれば大丈夫です。表空间被划分为许多连续的区，每个区默认由64个页组成，每256个区划分为一组，每个组的最开始的几个页面类型是固定的就好了
2.2 セグメント（Segment）の概念
テーブルに数十または数百のデータしかない場合など、テーブル内のデータの量が少ない場合は、対応するデータを数個の単純なページに格納できるため、領域の概念は実際には必要ありません。後の段階では、テーブル内にますます多くのレコードを保持できなくなります。
理論的には、エリアの概念を導入せずにページの概念のみを使用しても、ストレージ エンジンの動作には影響しませんが、次のシナリオを考えてみましょう。
- テーブルにレコードを挿入するたびに、基本的にテーブル
聚簇索引と、所有二级索引表現された B+ ツリーのノードにデータが挿入されます。そして、B+ ツリーの各層のページは、二重リンク リストを形成します (そうであれば)以页为单位来分配存储空间的话，双向链表相邻的两个页之间的物理位置可能离得非常远。B+ ツリー インデックスの適用可能なシナリオを紹介したときに范围查询只需要定位到最左边的记录和最右边的记录、二重リンク リストに沿ってスキャンするだけで十分であること、およびリンク リスト内に 2 つの隣接するページがある場合、物理位置离得非常远それがいわゆる であると具体的に述べました随机I/O。
ヒント:
ディスクの速度はメモリの速度とは数桁異なり、ランダム I/O は非常に遅いため、リンク リスト内の隣接するページの物理的位置を互いに隣接させるようにする必要があります。範囲クエリを実行する場合にのみ、いわゆるシーケンシャル I/O を使用できるようにします。
そのため、範囲の概念が導入されました一个区就是在物理位置上连续的64个页（1M）。テーブル内のデータ量が多い場合、インデックスに領域を割り当てるとき、ページ単位ではなく領域単位で割り当てられます。テーブル内のデータが非常に大きい場合でも、インデックスに領域が割り当てられることがあります。複数の連続した領域を割り当てます。多少のスペースの無駄（領域全体を埋めるにはデータが不十分）が発生する可能性がありますが、パフォーマンスの観点からは、大量のランダム I/O を排除でき、メリットがデメリットを上回ります。
先ほど述べた範囲クエリは実際には であり对B+树叶子节点中的记录进行顺序扫描、リーフ ノードと非リーフ ノードを区別せず、ノードによって表されるすべてのページを適用領域に配置すると、範囲スキャンの効果は大幅に減少します。したがって、InnoDB は、B+ ツリーのリーフ ノードと非リーフ ノードを異なる方法で処理します。つまり、叶子节点有自己独有的区、です非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段（segment），存放非叶子节点的区的集合也算是一个段。つまり一个索引会生成2个段，一个叶子节点段，一个非叶子节点段。
デフォルトでは、InnoDB ストレージ エンジンを使用するテーブルにはクラスター化インデックスが 1 つだけあり、インデックスは 2 つのセグメントを生成し、デフォルトで 1 つの領域が段是以区为单位申请存储空间1M のストレージ スペースを占有するため、レコードが数個しかない小さなテーブルにも 2M が必要です。収納スペース？今後インデックスを追加するたびに、さらに 2M のストレージ スペースを申請する必要がありますか?
これは、保存するレコードが少ないテーブルにとっては非常に無駄な行為です。InnoDB は非常に倹約的であり、もちろんこの状況は考慮されています。この問題の核心は、これまでに紹介した領域がすべて非常に純粋であること、つまり、領域が完全に特定のセグメントに割り当てられているか、領域内のすべてのページが同じセグメントのデータを格納するために存在していることです。セグメント データがゾーン内のすべてのページを埋めていない場合、残りのページは他の目的に使用できません。ここで、完全な領域の単位で特定のセグメントに割り当てることは、少量のデータを含むテーブルの記憶領域の無駄が多すぎるという事実を考慮するために、InnoDB は、断片化された領域では、すべてのページが領域に割り当てられるわけではないことを提案します一个碎片（fragment）区的概念。同じセグメントのデータが存在しますが、断片化された領域内のページは、セグメント A に使用されるページ、セグメント B に使用されるページ、セグメントにさえ属さないページなど、異なる目的に使用できます。 。断片化された領域は表スペースに直接属し、どのセグメントにも属しません。したがって、特定のセグメントにストレージ領域を割り当てる戦略は次のようになります。
-
テーブルへのデータの挿入の開始時に、セグメントは断片化された領域から単一ページ単位で記憶領域を割り当てます。
-
当某个段已经占用了32个碎片区页面之后、ストレージスペースは完全な領域の単位で割り当てられます。
したがって、セグメントは単に特定の領域の集合として定義することはできませんが、より正確には、いくつかの散在するページといくつかの完全な領域の集合である必要があります。インデックスのリーフ ノード セグメントと非リーフ ノード セグメントに加えて、InnoDB には、ロールバック セグメントなどの特別なデータを保存するために定義されたセグメントもあります。もちろん、今は他のタイプのセグメントは気にしません。セグメントとは、断片化されたページと完全なセクションの集合であることだけを知っておく必要があります。
2.3 ゾーンの分類
テーブルスペースはいくつかのエリアで構成されており、大きく次の 4 種類に分類できます。
-
空闲的区：このゾーンのページは現在使用されていません。 -
有剩余空间的碎片区：断片化された領域に利用可能なページがまだあることを示します。 -
没有剩余空间的碎片区：断片化された領域内のすべてのページが使用されており、空きページがないことを示します。 -
附属于某个段的区：各インデックスはリーフ ノード セグメントと非リーフ ノード セグメントに分割できます。さらに、InnoDB ではいくつかの特殊な目的のセグメントも定義されます。これらのセグメント内のデータ量が多い場合、その領域が基本割り当て単位として使用されます。 . .
これらの 4 種類のゾーンは、ゾーンの 4 つの状態とも呼ばれます。InnoDB は、ゾーンのこれら 4 つの状態に特定の名詞を定義します。
| 州名 | 意味 |
|---|---|
| 無料 | フリーエリア |
| free_frag | 空き領域のある断片化された領域 |
| フルフラグ | 断片化されスペースがなくなった領域 |
| fseg | セグメントにアタッチされたゾーン |
free、free_frag和full_fragこれら 3 つの州の学区は独立しているため、 であり直属于表空间、fseg州内の学区は であることを再度強調する必要があります附属于某个段。
ヒント
表スペースを国にたとえると、セグメントは州に相当し、地区は都市に相当します。fseg 州のすべての地区が特定のセグメントに属するのと同様に、一般的な都市は特定の州に属します。ただし、北京、天津、上海が直接国家管理下にあるのと同様に、free、free_frag、full_frag の 3 つの国家はテーブル スペースの直下にあります。
これらの領域の管理を容易にするために、InnoDB は XDES Entry (正式名は Extent Descriptor Entry) と呼ばれる構造を設計しました。各領域は、対応する領域のいくつかの属性を記録する XDES Entry 構造に対応します。この構造を一般的に理解するために、まず図を見てみましょう。
図からわかるように、XDES Entry は 40 バイトの構造であり、大きく 4 つの部分に分かれており、各部分の解釈は次のようになります。
-
セグメント ID (8 バイト)
各セグメントには固有の番号が付けられており、これを ID で表し、その領域が存在するセグメントを示します。もちろん、領域がセグメントに割り当てられていることが前提です。そうでない場合、このフィールドの値は意味がありません。 -
リスト ノード (12 バイト)
部分は、複数の XDES エントリ構造をリンク リストに接続できます。リスト ノードの構造を見てください。
表スペース内の特定の位置を特定したい場合は、ページ番号と、指定されたページ番号内の位置のページ・オフセットを指定するだけで済みます。それで：-
Prev Node Page Number と Prev Node Offset の組み合わせは、前の XDES エントリへのポインタです。
-
次のノード ページ番号と次のノード オフセットの組み合わせは、次の XDES エントリへのポインタです。
-
-
State (4 バイト)
このフィールドはゾーンの状態を示します。オプションの値は、前述の 4 つ、つまり free、free_frag、full_frag、fseg です。 -
Page State Bitmap (16 バイト)
この部分は合計 16 バイト、つまり 128 ビットを占めます。エリアにはデフォルトで 64 ページがあり、これらの 128 ビットは 64 の部分に分割され、各部分はエリア内のページに対応する 2 ビットを持ちます。たとえば、ページ ステート ビットマップ部分の 1 番目と 2 番目のビットは領域の 1 番目のページに対応し、3 番目と 4 番目のビットは領域の 2 番目のページに対応し、以下同様にページ ステート ビットマップ部分の 127 番目と 128 番目のビットが対応します。ゾーン内の 64 番目のページに対応するビット。これら 2 ビットの最初のビットは、対応するページが空いているかどうかを示し、2 番目のビットはまだ使用されていません
2.4 XDES エントリのリンク リスト
これまでエリア、セグメント、フラグメントエリア、セグメントに付属するエリア、XDES Entryなどの概念を提案してきましたが、そもそも面倒なことをするのは、データ量を減らさずにテーブルへのデータ挿入を効率化したいだけです。データの量。テーブルはスペースを無駄にしています。これで、テーブルにデータを挿入するということは、基本的に、テーブル内の各インデックスのリーフ ノード セグメントと非リーフ ノード セグメントにデータを挿入することであることがわかりました。また、異なる領域には異なる状態があることもわかり、その後、元の開始点に戻りますセグメントにデータを挿入するプロセス:
-
セグメント内のデータが少ない場合、
free_frag表スペース内にステータスが の領域があるかどうか、つまり、空き領域のある断片化された領域があるかどうかが最初にチェックされ、見つかった場合は、セグメントから分散ページがいくつか取得されます。freeそれ以外の場合は、表スペースに移動して、状態が の領域、つまり空き領域を申請し、その領域の状態を free_frag に変更してから、新しい領域から断片化されたページをいくつか取得します。適用された領域を選択し、そこにデータを挿入します。その後、別のセグメントが断片化されたページを使用する場合、この領域に空き領域がなくなるまでこの領域から断片化されたページが取得され、この領域のステータスは full_frag になります。ここでの問題は、表スペース内のどの領域が空いているか、どの領域が free_frag で、どの領域が full_frag であるかをどのようにして知るかということです。テーブル スペースのサイズは継続的に増加できることを知っておく必要があります。GB レベルまで増加すると、地区の数は数千になります。これらの地区に対応する XDES エントリ構造を毎回トラバースすることはできませんよね? このとき、XDES Entry のリスト ノード部分が奇跡的な効果を発揮します。リスト ノード内のポインタを介して 3 つのことが実行できます。
フリー領域に対応する XDES Entry 構造をリスト ノードを介して接続してリンク リストを形成し、このリンク リストをフリー リンク リストと呼びます。
-
free_frag 状態の領域に対応する XDES Entry 構造体をリストノードを介して連結リストに接続し、この連結リストを free_frag 連結リストと呼びます。
-
ステータスが full_frag である領域に対応する XDES Entry 構造体をリスト ノードを介して連結リストに接続します (この連結リストを full_frag 連結リストと呼びます)。
このようにして、free_frag 状態領域を見つけたいときはいつでも、free_frag リンク リストのヘッド ノードを直接取り出し、このノードから散在するページをいくつか取り出してデータを挿入し、このノードに対応する領域が使用されるときにそれを変更します。このノードの状態フィールドの値は、free_frag リンク リストから full_frag リンク リストに移動されます。同様に、free_frag リンク リストにノードがない場合は、free_frag リンク リストの状態に直接ノードを取得して、free_frag リンク リストの状態に移動し、ノードの state フィールド値を free_frag に変更して、このノードに対応する領域のフラグメント ページは問題ありません。
-
-
セグメント内のデータが散在 32 ページを占める場合は、完全な領域を直接申請してデータを挿入します。
同じ質問ですが、どのエリアがどのセグメントに属しているかをどのようにして知ることができるのでしょうか? 次に、各 XDES エントリ構造を走査しますか? 横断することは不可能であり、この世で横断することは不可能です。リンクされたリストがあり、それは毛糸です。それでは、fseg 領域に対応するすべての xdes エントリ構造をリンク リストに追加しますか? 愚かなことに、異なるセグメントが 1 つの領域を共有するにはどうすればよいでしょうか? インデックス a のリーフ ノード セグメントとインデックス b のリーフ ノード セグメントの両方を 1 つのゾーンに格納しますか? 当然、各セグメントに独自のリンク リストが必要なので、セグメント番号 (つまり、セグメント ID) に基づいてリンク リストを作成できます。セグメントの数と同じ数のリンク リストを作成できますか? これは少し問題のように思えます。セグメントには多くの領域が存在する可能性があり、一部の領域は完全に無料であり、一部の領域にはまだ使用可能なページがあり、一部の領域には使用できる空きページがないため、引き続き作業を行う必要があります。詳細な点では、innodb は各セグメントのゾーンに対応する xdes エントリ構造の 3 つのリンク リストを作成します。
- フリーリンクリスト: 同じセグメント内で、すべてのページがフリーの領域に対応する XDES エントリ構造が、このリンクリストに追加されます。なお、表スペースに直接属するフリーリンクリストとは異なり、あるセグメントに付随するフリーリンクリストとなります。
- not_full リンク リスト: 同じセグメント内で、まだ空き領域がある領域に対応する XDES エントリ構造が、このリンク リストに追加されます。
- フルリンクリスト: 同じセグメント内で、空き領域のない領域に対応する XDES エントリ構造がこのリンクリストに追加されます。
各インデックスは 2 つのセグメントに対応し、各セグメントは上記の 3 つのリンクされたリストを維持することを再度強調します。たとえば、以下の表を考えてみましょう。
create table demo9 (c1 int not null auto_increment,c2 varchar(100),c3 varchar(100),primary key (c1), key idx_c2 (c2));
このテーブル t にはクラスタード インデックスとセカンダリ インデックス idx_c2 の 2 つのインデックスがあるため、このテーブルには合計 4 つのセグメントがあり、各セグメントは上記の 3 つのリンク リスト、合計 12 のリンク リストを維持します。これに加えて、上記で説明したものがあります。表スペースに直接属する 3 つのリンク・リストと、独立表スペース全体で合計 15 のリンク・リストを維持する必要があります。したがって、セグメントがデータ量が比較的多い場合にデータを挿入する場合、まず not_full リンクリストの先頭ノードを取得し、その先頭ノードに対応する領域に直接データを挿入します。使い果たされた場合は、ノードを完全なリンク リストに移動します。
2.4.1 リンクリストベースノード
上記で紹介したリンク リストはたくさんありますが、これらのリンク リストを見つけるにはどうすればよいですか。また、テーブル スペース内でリンク リストの先頭ノードまたは末尾ノードの位置を見つけるにはどうすればよいでしょうか。もちろん、InnoDB はこの問題を考慮して、List Base Node と呼ばれる構造を設計しました。これは、リンクされたリストのベース ノードとして中国語に翻訳されます。この構造には、リンク リストの先頭ノードと末尾ノードへのポインタと、リンク リストに含まれるノードの数に関する情報が含まれています。この構造の概略図を確認するために図を描いてみましょう。
上で紹介した各リンク リストは、次のようなリスト ベース ノード構造に対応します。
- リストの長さは、リンクされたリストに含まれるノードの数を示します。
- 最初のノードのページ番号と最初のノードのオフセットは、表スペース内のリンク リストのヘッド ノードの位置を示します。
- 最終ノード ページ番号と最終ノード オフセットは、表スペース内のリンク リストの末尾ノードの位置を示します。
一般に、特定のリンク リストを見つけるのが非常に簡単になるように、特定のリンク リストに対応するリスト ベース ノード構造をテーブル スペース内の固定位置に配置します。
2.4.2 リンクリストの概要
つまり、テーブルスペースは複数の領域で構成されており、各領域は XDES Entry 構造に対応しており、テーブルスペースに直接属する領域に対応する XDES Entry 構造は、free、free_frag、free_frag の 3 つのリンクリストに分割できます。 full_frag; セグメントは複数の領域に接続でき、各セグメント内の領域に対応する XDES Entry 構造は、free、not_full、full の 3 つのリンク リストに分割できます。各リンク リストは、リンク リストの先頭ノードと末尾ノードの位置、およびリンク リストに含まれるノードの数を記録するリスト ベース ノード構造に対応します。これらのリンク リストの存在により、これらの領域の管理が非常に簡単になりました。
2.4.3 セクション構造
前に述べたように、セグメントは実際には表領域内の連続した物理領域に対応するのではなく、いくつかの分散したページといくつかの完全な領域で構成される論理的な概念です。各ゾーンには、このゾーンの属性を記録するための対応する XDES エントリがあるのと同様に、InnoDB は、セグメント内の属性を記録するために各セグメントの INODE エントリ構造を定義します。概略図を見てみましょう。
そのさまざまな部分を次のように説明します。
-
セグメント ID は、
INODE Entry 構造に対応するセグメントの番号 (ID) を指します。 -
NOT_FULL_N_USED
フィールドは、NOT_FULL リンク リストで使用されたページ数を示します。 -
3 つのリスト ベース ノードは、
セグメントのフリー リンク リスト、not_null リンク リスト、フル リンク リストのリスト ベース ノードをそれぞれ定義します。これにより、特定のセグメントのリンク リストの先頭ノードと末尾ノードを見つけたい場合、この部分に直接移動して、リンクされたリストのリスト ベース ノードに対応するものを見つけることができます。 -
マジック ナンバーの値
は、INODE エントリが初期化されているかどうかをマークするために使用されます (初期化とは、各フィールドの値を埋めることを意味します)。この数値が 97937874 の値である場合は、INODE エントリが初期化されていることを示します。それ以外の場合は、初期化されていません。(この値の特別な意味や規制については心配する必要はありません)。 -
Fragment Array Entry
セグメントは、いくつかの断片化されたページといくつかの完全な領域のコレクションです。各 Fragment Array Entry 構造は、断片化されたページに対応します。この構造体には合計 4 バイトがあり、断片化されたページのページ番号を示します。
この INODE エントリ構造と組み合わせると、散在するページといくつかの完全な領域の集合としてのセグメントについてより深く理解できるようになります。
2.4.4 FSP_HDR タイプ
表領域の最初のページ、ページ番号 0。このページのタイプは FSP_HDR で、表スペースのいくつかの全体的な属性と、最初のグループの 256 地区の対応する XDES エントリー構造が保管されます。このタイプのページの概略図を直接参照してください。
完全な FSP_HDR タイプのページは大きく 5 つの部分で構成されており、各部分の具体的な解釈は次のとおりです。
| 名前 | 中国語の名前 | 占有スペースのサイズ | 簡単な説明 |
|---|---|---|---|
| ファイルヘッダー | ファイルヘッダー | 38バイト | ページ上の一般的な情報 |
| ファイルスペースヘッダー | テーブルスペースヘッダー | 112バイト | 表スペースの全体的な属性情報の一部 |
| XDES エントリ | 地区の説明情報 | 10240バイト | このグループに256地区に対応する属性情報を格納します |
| 空きスペース | 未使用スペース | 5986バイト | ページ構造を埋めるために使用されますが、実際的な意味はありません。 |
| ファイルトレーラー | ファイルの終わり | 8バイト | 認証ページが完了しているかどうか |
ファイル ヘッダーとファイル トレーラーは強調されなくなりました。他の部分のうち、空きスペースは未使用のスペースです。これを無視して、ファイル スペース ヘッダーと XDES エントリの 2 つの部分に注目してみましょう。
File Space Header部分
この部分は、表スペースの全体的な属性情報を保管するために使用されます。詳細については、次の図を参照してください。
各属性の簡単な説明は次のとおりです。
| 名前 | 占有スペースのサイズ | 説明 |
|---|---|---|
| スペースID | 4バイト | テーブルスペースのID |
| 使用されていない | 4バイト | これらの 4 バイトは使用されないため、無視できます。 |
| サイズ | 4バイト | 現在のテーブルスペースが占有しているページ数 |
| 無料制限 | 4バイト | 初期化されていない最小ページ番号、およびこのページ番号以上の領域に対応する XDES エントリ構造が FREE リストに追加されていません |
| スペースフラグ | 4バイト | 比較的小さな記憶域を占有する表スペースの一部の属性 |
| FRAG_N_USED | 4バイト | FREE_FRAG リンク リストで使用されるページ数 |
| 無料リストのベースノードをリストする | 16バイト | FREEリンクリストのベースノード |
| FREE_FRAG リストのベース ノードのリスト | 16バイト | FREE_FRAG リンク リストのベース ノード |
| FULL_FRAG リストのリスト ベース ノード | 16バイト | FULL_FRAG リンク リストのベース ノード |
| 次の未使用セグメント ID | 8バイト | 現在のテーブルスペース内の次の未使用セグメント ID |
| List Base Node for SEG_INODES_FULL List | 16字节 | SEG_INODES_FULL链表的基节点 |
| List Base Node for SEG_INODES_FREE List | 16字节 | SEG_INODES_FREE链表的基节点 |
这里头的Space ID、Not Used、Size这三个字段大家肯定一看就懂，其他的字段我们再详细看一下：
-
List Base Node for FREE List、List Base Node for FREE_FRAG List、List Base Node for FULL_FRAG List
这三个大家看着太亲切了，分别是直属于表空间的FREE链表的基节点、FREE_FRAG链表的基节点、FULL_FRAG链表的基节点，这三个链表的基节点在表空间的位置是固定的，就是在表空间的第一个页面（也就是FSP_HDR类型的页面）的File Space Header部分。所以之后定位这几个链表就很简单啦。 -
FRAG_N_USED
这个字段表明在FREE_FRAG链表中已经使用的页面数量。 -
FREE Limit
我们知道表空间都对应着具体的磁盘文件，一开始我们创建表空间的时候对应的磁盘文件中都没有数据，所以我们需要对表空间完成一个初始化操作，包括为表空间中的区建立XDES Entry结构，为各个段建立INODE Entry结构，建立各种链表的各种操作。我们可以一开始就为表空间申请一个特别大的空间，但是实际上有绝大部分的区是空闲的，我们可以选择把所有的这些空闲区对应的XDES Entry结构加入FREE链表，也可以选择只把一部分的空闲区加入FREE链表，等啥时候空闲链表中的XDES Entry结构对应的区不够使了，再把之前没有加入FREE链表的空闲区对应的XDES Entry结构加入FREE链表，中心思想就是啥时候用到啥时候初始化，InnoDB采用的就是后者，他们为表空间定义了FREE Limit这个字段，在该字段表示的页号之前的区都被初始化了，之后的区尚未被初始化。 -
Next Unused Segment ID
表中每个索引都对应2个段，每个段都有一个唯一的ID，那当我们为某个表新创建一个索引的时候，就意味着要创建两个新的段。那怎么为这个新创建的段找一个唯一的ID呢？去遍历现在表空间中所有的段么？我们说过，遍历是不可能遍历的，这辈子都不可能遍历，InnoDB提出了这个名叫Next Unused Segment ID的字段，该字段表明当前表空间中最大的段ID的下一个ID，这样在创建新段的时候赋予新段一个唯一的ID值就so easy啦，直接使用这个字段的值就好了。 -
Space Flags
表空间对于一些布尔类型的属性，或者只需要寥寥几个比特位搞定的属性都放在了这个Space Flags中存储，虽然它只有4个字节，32个比特位大小，却存储了好多表空间的属性，详细情况如下表：
| 标志名称 | 占用空间（单位：bit） | 描述 |
|---|---|---|
| POST_ANTELOPE | 1 | 表示文件格式是否大于ANTELOPE |
| ZIP_SSIZE | 4 | 表示压缩页面的大小 |
| ATOMIC_BLOBS | 1 | 表示是否自动把值非常长的字段放到BLOB页里 |
| PAGE_SIZE | 4 | 页面大小 |
| DATA_DIR | 1 | 表示表空间是否是从默认的数据目录中获取的 |
| SHARED | 1 | 是否为共享表空间 |
| TEMPORARY | 1 | 是否为临时表空间 |
| ENCRYPTION | 1 | 表空间是否加密 |
| UNUSED | 18 | 没有使用到的比特位 |
-
List Base Node for SEG_INODES_FULL List和List Base Node for SEG_INODES_FREE List
每个段对应的INODE Entry结构会集中存放到一个类型为INODE的页中，如果表空间中的段特别多，则会有多个INODE Entry结构，可能一个页放不下，这些INODE类型的页会组成两种列表：-
SEG_INODES_FULL链表，该链表中的INODE类型的页面都已经被INODE Entry结构填充满了，没空闲空间存放额外的INODE Entry了。
-
SEG_INODES_FREE链表，该链表中的INODE类型的页面仍有空闲空间来存放INODE Entry结构。
由于我们现在还没有详细介绍INODE类型页，所以等会说过INODE类型的页之后再回过头来看着两个链表。
-
XDES Entry部分
紧接着File Space Header部分的就是XDES Entry部分了，我们嘴上说过无数次，却从没见过真身的XDES Entry就是在表空间的第一个页面中保存的。我们知道一个XDES Entry结构的大小是40字节，但是一个页面的大小有限，只能存放有限个XDES Entry结构，所以我们才把256个区划分成一组，在每组的第一个页面中存放256个XDES Entry结构。大家回看那个FSP_HDR类型页面的示意图，XDES Entry 0就对应着extent 0，XDES Entry 1就对应着extent 1… 依此类推，XDES Entry255就对应着extent 255。
因为每个区对应的XDES Entry结构的地址是固定的，所以我们访问这些结构就非常简单啦。
2.4.5 XDES类型
每一个XDES Entry结构对应表空间的一个区，虽然一个XDES Entry结构只占用40字节，但你抵不住表空间的区的数量也多啊。在区的数量非常多时，一个单独的页可能就不够存放足够多的XDES Entry结构，所以我们把表空间的区分为了若干个组，每组开头的一个页面记录着本组内所有的区对应的XDES Entry结构。由于第一个组的第一个页面有些特殊，因为它也是整个表空间的第一个页面，所以除了记录本组中的所有区对应的XDES Entry结构以外，还记录着表空间的一些整体属性，这个页面的类型就是我们刚刚说完的FSP_HDR类型，整个表空间里只有一个这个类型的页面。除去第一个分组以外，之后的每个分组的第一个页面只需要记录本组内所有的区对应的XDES Entry结构即可，不需要再记录表空间的属性了，为了和FSP_HDR类型做区别，我们把之后每个分组的第一个页面的类型定义为XDES，它的结构和FSP_HDR类型是非常相似的：
与FSP_HDR类型的页面对比，除了少了File Space Header部分之外，也就是除了少了记录表空间整体属性的部分之外，其余的部分是一样一样的。
2.4.6 IBUF_BITMAP类型
每个分组的第二个页面的类型都是IBUF_BITMAP，这种类型的页里边记录了一些有关Change Buffer的信息。
2.4.7 INODE类型
再次对比前边介绍表空间的图，第一个分组的第三个页面的类型是INODE。我们前边说过InnoDB为每个索引定义了两个段，而且为某些特殊功能定义了些特殊的段。为了方便管理，他们又为每个段设计了一个INODE Entry结构，这个结构中记录了关于这个段的相关属性。而我们这会儿要介绍的这个INODE类型的页就是为了存储INODE Entry结构而存在的。
一个INODE类型的页面是由这几部分构成的：
| 名称 | 中文名 | 占用空间大小 | 简单描述 |
|---|---|---|---|
| File Header | 文件头部 | 38字节 | 页的一些通用信息 |
| List Node for INODE Page List | 通用链表节点 | 12字节 | 存储上一个INODE页面和下一个INODE页面的指针 |
| INODE Entry | 段描述信息 | 16320字节 | 存储段描述信息 |
| Empty Space | 尚未使用空间 | 6字节 | 用于页结构的填充，没啥实际意义 |
| File Trailer | 文件尾部 | 8字节 | 校验页是否完整 |
除了File Header、Empty Space、File Trailer这几个老朋友外，我们重点关注List Node for INODE Page List和INODE Entry这两个部分。
首先看INODE Entry部分，我们前边已经详细介绍过这个结构的组成了，主要包括对应的段内零散页面的地址以及附属于该段的FREE、NOT_FULL和FULL链表的基节点。每个INODE Entry结构占用192字节，一个页面里可以存储85个这样的结构。
重点看一下List Node for INODE Page List，因为一个表空间中可能存在超过85个段，所以可能一个INODE类型的页面不足以存储所有的段对应的INODE Entry结构，所以就需要额外的INODE类型的页面来存储这些结构。还是为了方便管理这些INODE类型的页面，InnoDB将这些INODE类型的页面串联成两个不同的链表：
- SEG_INODES_FULL链表：该链表中的INODE类型的页面中已经没有空闲空间来存储额外的INODE Entry结构了。
- SEG_INODES_FREE链表：该链表中的INODE类型的页面中还有空闲空间来存储额外的INODE Entry结构了。
想必大家已经认出这两个链表了，我们前边提到过这两个链表的基节点就存储在File Space Header里边，也就是说这两个链表的基节点的位置是固定的，所以我们可以很轻松的访问到这两个链表。以后每当我们新创建一个段（创建索引时就会创建段）时，都会创建一个INODE Entry结构与之对应，存储INODE Entry的大致过程就是这样的：
- 先看看SEG_INODES_FREE链表是否为空，如果不为空，直接从该链表中获取一个节点，也就相当于获取到一个仍有空闲空间的INODE类型的页面，然后把该INODE Entry结构放到该页面中。当该页面中无剩余空间时，就把该页放到SEG_INODES_FULL链表中。
- 如果SEG_INODES_FREE链表为空，则需要从表空间的FREE_FRAG链表中申请一个页面，修改该页面的类型为INODE，把该页面放到SEG_INODES_FREE链表中，与此同时把该INODE Entry结构放入该页面
2.4.8 Segment Header结构的运用
我们知道一个索引会产生两个段，分别是叶子节点段和非叶子节点段，而每个段都会对应一个INODE Entry结构，那我们怎么知道某个段对应哪个INODE Entry结构呢？所以得找个地方记下来这个对应关系。记得之前学习过的数据页MySQL之数据页结构，也就是INDEX类型的页有一个Page Header部分，所以把Page Header部分粘一下：
其中的PAGE_BTR_SEG_LEAF和PAGE_BTR_SEG_TOP都占用10个字节，它们其实对应一个叫Segment Header的结构，该结构图示如下：
各个部分的具体释义如下：
| 名称 | 占用空间大小 | 描述 |
|---|---|---|
| Space ID of the INODE Entry | 4字节 | INODE Entry结构所在的表空间ID |
| Page Number of the INODE Entry | 4字节 | INODE Entry结构所在的页面页号 |
| Byte Offset of the INODE Entry | 2字节 | INODE Entry结构在该页面中的偏移量 |
这样子就很清晰了，PAGE_BTR_SEG_LEAF记录着叶子节点段对应的INODE Entry结构的地址是哪个表空间的哪个页面的哪个偏移量，PAGE_BTR_SEG_TOP记录着非叶子节点段对应的INODE Entry结构的地址是哪个表空间的哪个页面的哪个偏移量。这样子索引和其对应的段的关系就建立起来了。不过需要注意的一点是，因为一个索引只对应两个段，所以只需要在索引的根页面中记录这两个结构即可。
2.5 真实表空间对应的文件大小
上边的这些概念已经压的快喘不过气了。不过独立表空间有那么大么？我到数据目录里看了，一个新建的表对应的.ibd文件只占用了96K，才6个页面大小，上边的说了那么多概念，那么大的空间占用，为什么只有96KB大小？
一开始表空间占用的空间自然是很小，因为表里边都没有数据。.ibd文件是自扩展的，随着表中数据的增多，表空间对应的文件也逐渐增大。
三、系统表空间结构
了解完了独立表空间的基本结构，系统表空间的结构也就好理解多了，系统表空间的结构和独立表空间基本类似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页面，所以会比独立表空间多出一些记录这些信息的页面。因为这个系统表空间最厉害，相当于是表空间之首，所以它的表空间 ID（Space ID）是0。
3.1 系统表空间整体结构
系统表空间与独立表空间的一个非常明显的不同之处就是在表空间开头有许多记录整个系统属性的页面，如图：
可以看到，系统表空间和独立表空间的前三个页面（页号分别为0、1、2，类型分别是FSP_HDR、IBUF_BITMAP、INODE）的类型是一致的，只是页号为3～7的页面是系统表空间特有的，我们来看一下这些多出来的页面都是干啥使的：
| 页号 | 页面类型 | 英文描述 | 描述 |
|---|---|---|---|
| 3 | SYS | Insert Buffer Header | 存储Insert Buffer的头部信息 |
| 4 | INDEX | Insert Buffer Root | 存储Insert Buffer的根页面 |
| 5 | TRX_SYS | Transction System | 事务系统的相关信息 |
| 6 | SYS | First Rollback Segment | 第一个回滚段的页面 |
| 7 | SYS | Data Dictionary Header | 数据字典头部信息 |
除了这几个记录系统属性的页面之外，系统表空间的extent 1和extent 2这两个区，也就是页号从64~191这128个页面被称为Doublewrite buffer，不过上述的大部分知识都涉及到了事务和多版本控制的问题，这些问题我们会放在后边的章节中进行学习，所以现在我们只学习下有关InnoDB数据字典的知识，其余的概念在后边再看
3.2 InnoDB数据字典
我们平时使用INSERT语句向表中插入的那些记录称之为用户数据，MySQL只是作为一个软件来为我们来保管这些数据，提供方便的增删改查接口而已。但是每当我们向一个表中插入一条记录的时候，MySQL先要校验一下插入语句对应的表存不存在，插入的列和表中的列是否符合，如果语法没有问题的话，还需要知道该表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面，然后把记录插入对应索引的B+树中。所以说，MySQL除了保存着我们插入的用户数据之外，还需要保存许多额外的信息，比方说：
- 某个表属于哪个表空间，表里边有多少列
- 表对应的每一个列的类型是什么
- 该表有多少索引，每个索引对应哪几个字段，该索引对应的
- 页面在哪个表空间的哪个页面
- 该表有哪些外键，外键对应哪个表的哪些列
- 某个表空间对应文件系统上文件路径是什么等等
上述这些数据并不是我们使用INSERT语句插入的用户数据，实际上是为了更好的管理我们这些用户数据而不得已引入的一些额外数据，这些数据也称为元数据。InnoDB存储引擎特意定义了一些列的内部系统表（internal system table）来记录这些这些元数据：
| 表名 | 描述 |
|---|---|
| SYS_TABLES | 整个InnoDB存储引擎中所有的表的信息 |
| SYS_COLUMNS | 整个InnoDB存储引擎中所有的列的信息 |
| SYS_INDEXES | 整个InnoDB存储引擎中所有的索引的信息 |
| SYS_FIELDS | 整个InnoDB存储引擎中所有的索引对应的列的信息 |
| SYS_FOREIGN | 整个InnoDB存储引擎中所有的外键的信息 |
| SYS_FOREIGN_COLS | 整个InnoDB存储引擎中所有的外键对应列的信息 |
| SYS_TABLESPACES | 整个InnoDB存储引擎中所有的表空间信息 |
| SYS_DATAFILES | 整个InnoDB存储引擎中所有的表空间对应文件系统的文件路径信息 |
| SYS_VIRTUAL | 整个InnoDB存储引擎中所有的虚拟生成列的信息 |
这些系统表也被称为数据字典，它们都是以B+树的形式保存在系统表空间的某些页面中，其中SYS_TABLES、SYS_COLUMNS、SYS_INDEXES、SYS_FIELDS这四个表尤其重要，称之为基本系统表（basic system tables），我们先看看这4个表的结构。
3.2.1 SYS_TABLES 表
SYS_TABLES表的列
| 列名 | 描述 |
|---|---|
| NAME | 表的名称 |
| ID | InnoDB存储引擎中每个表都有一个唯一的ID |
| N_COLS | 该表拥有列的个数 |
| TYPE | 表的类型，记录了一些文件格式、行格式、压缩等信息 |
| MIX_ID | 已过时，忽略 |
| MIX_LEN | 表的一些额外的属性 |
| CLUSTER_ID | 未使用，忽略 |
| SPACE | 该表所属表空间的ID |
这个SYS_TABLES表有两个索引：
- 以
NAME列为主键的聚簇索引 - 以
ID列建⽴的二级索引
3.2.2 SYS_COLUMNS表
SYS_COLUMNS表的列
| 列名 | 描述 |
|---|---|
| TABLE_ID | 该列所属表对应的ID |
| POS | 该列在表中是第几列 |
| NAME | 该列的名称 |
| MTYPE | main data type，主数据类型，就是那堆INT、CHAR、VARCHAR、FLOAT、DOUBLE之类的等 |
| PRTYPE | precise type，精确数据类型，就是修饰主数据类型的那堆东东，比如是否允许NULL值，是否允许负数啥的 |
| LEN | 该列最多占用存储空间的字节数 |
| PREC | 该列的精度，不过这列貌似都没有使用，默认值都是0 |
这个SYS_COLUMNS表只有一个聚集索引：
- 以
(TABLE_ID, POS)列为主键的聚簇索引
3.2.3 SYS_INDEXES表
SYS_INDEXES表的列
| 列名 | 描述 |
|---|---|
| TABLE_ID | 该索引所属表对应的ID |
| ID | InnoDB存储引擎中每个索引都有一个唯一的ID |
| NAME | 该索引的名称 |
| N_FIELDS | 该索引包含列的个数 |
| TYPE | 该索引的类型，比如聚簇索引、唯一索引、更改缓冲区的索引、全文索引、普通的二级索引等等各种类型 |
| SPACE | 该索引根页面所在的表空间ID |
| PAGE_NO | 该索引根页面所在的页面号 |
| MERGE_THRESHOLD | 如果页面中的记录被删除到某个比例，就把该页面和相邻页面合并，这个值就是这个比例 |
这个SYS_INEXES表只有一个聚集索引：
- 以
(TABLE_ID, ID)列为主键的聚簇索引
3.2.4 SYS_FIELDS表
SYS_FIELDS表的列
| 列名 | 描述 |
|---|---|
| INDEX_ID | 该索引列所属的索引的ID |
| POS | 该索引列在某个索引中是第几列 |
| COL_NAME | 该索引列的名称 |
这个SYS_INEXES表只有一个聚集索引：
- 以
(INDEX_ID, POS)列为主键的聚簇索引
3.3 Data Dictionary Header页面
只要有了上述4个基本系统表，也就意味着可以获取其他系统表以及用户定义的表的所有元数据。比方说我们想看看SYS_TABLESPACES这个系统表里存储了哪些表空间以及表空间对应的属性，那就可以：
-
到
SYS_TABLES表中根据表名定位到具体的记录，就可以获取到SYS_TABLESPACES表的TABLE_ID -
使用这个
TABLE_ID到SYS_COLUMNS表中就可以获取到属于该表的所有列的信息。 -
使用这个
TABLE_ID还可以到SYS_INDEXES表中获取所有的索引的信息，索引的信息中包括对应的INDEX_ID，还记录着该索引对应的B+数根页面是哪个表空间的哪个页面。 -
使用
INDEX_ID就可以到SYS_FIELDS表中获取所有索引列的信息。
也就是说这4个表是表中之表，那这4个表的元数据去哪里获取呢？没法搞了，只能把这4个表的元数据，就是它们有哪些列、哪些索引等信息硬编码到代码中，然后InnoDB拿出一个固定的页面来记录这4个表的聚簇索引和二级索引对应的B+树位置，这个页面就是页号为7的页面，类型为SYS，记录了Data Dictionary Header，也就是数据字典的头部信息。除了这4个表的5个索引的根页面信息外，这个页号为7的页面还记录了整个InnoDB存储引擎的一些全局属性：
可以看到这个页面由下边几个部分组成：
| 名称 | 中文名 | 占用空间大小 | 简单描述 |
|---|---|---|---|
| File Header | 文件头部 | 38字节 | 页的一些通用信息 |
| Data Dictionary Header | 数据字典头部信息 | 56字节 | 记录一些基本系统表的根页面位置以及InnoDB存储引擎的一些全局信息 |
| Segment Header | 段头部信息 | 10字节 | 记录本页面所在段对应的INODE Entry位置信息 |
| Empty Space | 尚未使用空间 | 16272字节 | 用于页结构的填充，没啥实际意义 |
| File Trailer | 文件尾部 | 8字节 | 校验页是否完整 |
可以看到这个页面里竟然有Segment Header部分，意味着InnoDB把这些有关数据字典的信息当成一个段来分配存储空间，我们就姑且称之为数据字典段吧。由于目前我们需要记录的数据字典信息非常少（可以看到Data Dictionary Header部分仅占用了56字节），所以该段只有一个碎片页，也就是页号为7的这个页。
接下来我们需要细细说一下Data Dictionary Header部分的各个字段：
-
Max Row ID：我们说过如果我们不显式的为表定义主键，而且表中也没有UNIQUE索引，那么InnoDB存储引擎会默认为我们生成一个名为row_id的列作为主键。因为它是主键，所以每条记录的row_id列的值不能重复。原则上只要一个表中的row_id列不重复就可以了，也就是说表a和表b拥有一样的row_id列也没啥关系，不过InnoDB只提供了这个Max Row ID字段，不论哪个拥有row_id列的表插入一条记录时，该记录的row_id列的值就是Max Row ID对应的值，然后再把Max Row ID对应的值加1，也就是说这个Max Row ID是全局共享的。 -
Max Table ID：InnoDB存储引擎中的所有的表都对应一个唯一的ID，每次新建一个表时，就会把本字段的值作为该表的ID，然后自增本字段的值。 -
Max Index ID：InnoDB存储引擎中的所有的索引都对应一个唯一的ID，每次新建一个索引时，就会把本字段的值作为该索引的ID，然后自增本字段的值。Max Space ID：InnoDB存储引擎中的所有的表空间都对应一个唯一的ID，每次新建一个表空间时，就会把本字段的值作为该表空间的ID，然后自增本字段的值。 -
Mix ID Low(Unused)：这个字段没啥用，跳过。 -
Root of SYS_TABLES clust index：本字段代表SYS_TABLES表聚簇索引的根页面的页号。 -
Root of SYS_TABLE_IDS sec index：本字段代表SYS_TABLES表为ID列建立的二级索引的根页面的页号。 -
Root of SYS_COLUMNS clust index：本字段代表SYS_COLUMNS表聚簇索引的根页面的页号。 -
Root of SYS_INDEXES clust index：本字段代表SYS_INDEXES表聚簇索引的根页面的页号。 -
Root of SYS_FIELDS clust index：本字段代表SYS_FIELDS表聚簇索引的根页面的页号。 -
Unused：这4个字节没用，跳过。
以上就是页号为7的页面的全部内容，看一次肯定懵，一定要反复多看几次。
3.4 information_schema系统数据库
需要注意一点的是，用户是不能直接访问InnoDB的这些内部系统表的，除非你直接去解析系统表空间对应文件系统上的文件。不过InnoDB考虑到查看这些表的内容可能有助于大家分析问题，所以在系统数据库information_schema中提供了一些以innodb开头的表：
mysql> USE information_schema;
Database changed
mysql> show tables like 'in%';
+------------------------------------+
| Tables_in_information_schema (IN%) |
+------------------------------------+
| INNODB_BUFFER_PAGE |
| INNODB_BUFFER_PAGE_LRU |
| INNODB_BUFFER_POOL_STATS |
| INNODB_CACHED_INDEXES |
| INNODB_CMP |
| INNODB_CMP_PER_INDEX |
| INNODB_CMP_PER_INDEX_RESET |
| INNODB_CMP_RESET |
| INNODB_CMPMEM |
| INNODB_CMPMEM_RESET |
| INNODB_COLUMNS |
| INNODB_DATAFILES |
| INNODB_FIELDS |
| INNODB_FOREIGN |
| INNODB_FOREIGN_COLS |
| INNODB_FT_BEING_DELETED |
| INNODB_FT_CONFIG |
| INNODB_FT_DEFAULT_STOPWORD |
| INNODB_FT_DELETED |
| INNODB_FT_INDEX_CACHE |
| INNODB_FT_INDEX_TABLE |
| INNODB_INDEXES |
| INNODB_METRICS |
| INNODB_SESSION_TEMP_TABLESPACES |
| INNODB_TABLES |
| INNODB_TABLESPACES |
| INNODB_TABLESPACES_BRIEF |
| INNODB_TABLESTATS |
| INNODB_TEMP_TABLE_INFO |
| INNODB_TRX |
| INNODB_VIRTUAL |
+------------------------------------+
31 rows in set (0.00 sec)
在information_schema数据库中的这些以INNODB开头的表并不是真正的内部系统表（内部系统表就是我们上边唠叨的以SYS开头的那些表），而是在存储引擎启动时读取这些以SYS开头的系统表，然后填充到这些以INNODB_SYS开头的表中。以INNODB_SYS开头的表和以SYS开头的表中的字段并不完全一样，但供大家参考已经足矣。
四、总结
今天我们学习了关于InnoDB存储引擎表空间的结构，通篇几乎全是概念、图片，这部分知识本就枯燥乏味，但是’春天’马上就到来，最枯燥乏味的内容马上结束了。由于今天的内容都是偏理论的概念，加上篇幅原因，就不做知识点总结了。
今天的文章我第一次读原著时，一脸懵逼，好像知道了表空间结构是怎么一回事儿，但是好像又讲不出来什么，所以建议大家多看几次，我相信一句话：书读百遍，其义自见。当你一次看不懂的时候，就一定要多看几次。同时，建议大家多动手画一画结构图，这样理解起来更加深刻。
この記事を読んだことで、MySQL データベース設計の複雑さと繊細さを知りました。元の本の著者である子供 4919 はテクノロジーの研究に深く没頭しており、現時点では私には手が届きません。ですから、この偉人のペースに従って、毎日少しずつ進歩してください。皆さんも最終的には偉人になることを願っています。お互いに励まし合いましょう！
今日の勉強はこれで終わりです、あなたが壊れない自分になれることを願っています
~~~
先を見据えて点と点を結ぶことはできません。過去を振り返って接続することしかできません。したがって、点と点が何らかの形であなたの将来につながると信じなければなりません。あなたは何かを信頼しなければなりません - 自分の直感、運命、人生、カルマ、何でも。このアプローチは私を決して失望させず、私の人生に大きな変化をもたらしました
私のコンテンツがあなたのお役に立てましたら、どうぞ点赞、、、創作は簡単ではありません、皆さんのサポートが私が頑張れる原動力です评论收藏
