MySQL（InnoDB分析）：---テーブル（テーブルスペース：セグメント（セグメント）、エリア（エクステント）、ページ（ページ））

1つは、InnoDB論理ストレージ構造です。

 

• InnoDBの論理ストレージ構造の観点から、すべてのデータは、テーブルスペース（テーブルスペース）と呼ばれるスペースに論理的に格納されます。
• 表スペースは、セグメント（セグメント）、領域（範囲）、ページ（ページ）構成です。
• 一部のドキュメントでは、ページはブロックと呼ばれることもあります

次に、テーブルスペース

 

• 表スペースは、 InnoDBストレージ・エンジンの論理構造の最高レベルと見なすことができ、すべてのデータは表スペースに保管されます。

デフォルトのテーブルスペース

 

• 前回の記事では、InnoDBにはデフォルトで共有テーブルスペースibdata1があることを紹介しました。つまり、すべてのデータはこのテーブルスペースに格納されます。

show variables like 'innodb_data_file_path'\G;

 

innodb_file_per_tableパラメーター

 

• ユーザーがinnodb_file_per_tableパラメーターを有効にすると、各テーブルのデータを個別に表スペースに配置できます（詳細については、前の記事の紹介を参照してください：https ：//blog.csdn.net/qq_41453285/article/details/104115914）
• このパラメーターを使用する場合、各表の表スペースには、データ、索引および挿入バッファーのビットマップ・ページ、ロールバック（元に戻す）情報、挿入バッファー索引ページ、システム・トランザクション情報などの他のタイプのデータのみが保管されることに注意してください。二次書き込みバッファーなどは、元の共有表スペースに引き続き保管されます。

共有テーブルスペースのサイズ

 

• 上記のinnodb_file_per_tableパラメーターにより、テーブルごとに個別のテーブルスペースが使用されている場合でも、テーブルの一部の情報を共有テーブルスペースに格納する必要があるため、共有テーブルのスペースは引き続きサイズが大きくなります。
• 以下は、共有テーブルスペースのサイズの拡大プロセスを観察するためのデモンストレーションケースです。
• まず、innodb_dile_per_tableパラメーターを「NO」に設定します。次に、デフォルトの共有テーブルスペースファイルのサイズ（58M）を確認します。

• 次に、元に戻す操作をシミュレートします。autocommitを0に設定すると、ユーザーはトランザクションを明示的にコミットする必要があります（次の図では、トランザクションの送信の最後に、カルシウムフードに対してコミットまたはロールバックが実行されないため、多数の元に戻す操作の更新ステートメントの数が生成されます。）共有表スペースのサイズが増加していることがわかります。

• トランザクションがロールバックされた場合、共有テーブルスペースのサイズは元のサイズに縮小されますか？、下記参照

• 答えはノーです。共有表スペースのサイズは減少していません。InnoDBはこれらのスペースを再利用しませんが、元に戻す情報がまだ必要かどうかを自動的に判断します。必要がない場合は、これらのスペースを次の元に戻すための空きスペースとしてマークします。
• ユーザーが上記の更新ステートメントを再度実行すると、共有テーブルスペースファイルは以前の元に戻す情報を使用するため、これ以上増加しないことがわかります。

Pythonスクリプト：表スペースの各ページの情報を表示します

• このスクリプトはGitHubからダウンロードできます：https：//github.com/jameslcj/david-mysql-tools

 

• このスクリプトは、表スペースの各ページのタイプと情報を表示するために使用されます。使用方法は次のとおりです。

全部で83,584ページあります。バッファに挿入されるスペースのリストには、204ページ、5467空きページ、38675取り消しページ、39233データページなどがあります。

• ユーザーは-vオプションを使用してより詳細なコンテンツを表示できます

3つ目は、表スペースの「セグメント」です。

 

• 上の図から、表スペースが複数のセグメントで構成されていることがわかります。一般的なセグメントには、データ・セグメント、索引セグメント、ロールバック・セグメントなどが含まれます。
• 前述のように、InnoDBはインデックスで構成されているため、データはインデックスであり、インデックスはデータです。

1. その場合、データセグメントはB +ツリーのリーフノードです（リーフノードセグメント）
2. インデックスセグメントは、B +ツリーの非インデックスノードです（非リーフノードセグメント）。
3. ロールバックセグメントは非常に特別で、後で紹介します

InnoDBでは、セグメントの管理はストレージエンジン自体によって行われ、DBAはそのためのスペースを作成することはできません。これは、Oracleデータベースの自動セグメントスペース管理（ASSM）に似ており、DBAによるセグメントの管理をある程度簡素化します。

 

 

第4に、表スペースの「ゾーン」

• ゾーンは、連続したページで構成されるスペースです。
• いずれの場合も、各ゾーンのサイズは1MBです。ページ領域の連続性を確保するために、InnoDBストレージエンジンは4〜5ディスクアプリケーションゾーンの時間

地区のページ数

 

• デフォルトでは、InnoDBストレージエンジンのページサイズは16KBです。つまり、リージョン内に64の連続したページがあります。
• InnoDB 1.0.xは圧縮ページの導入を開始しました。つまり、各ページのサイズはパラメーターKEY_BLOCK_SIZEを使用して2K、4K、8Kに設定できるため、各ゾーンに対応するページ数は512、256、128になります。
• InnoDB 1.2.xは、新しいパラメーターinnodb_page_sizeを追加しました。これにより、デフォルトのページサイズを4Kまたは8Kに設定できます。ただし、ページ内のデータベースは圧縮されていません。このタイムゾーンのページ数も256、128です

つまり、ページサイズがどのように変化しても、領域サイズは常に1Mです。

地区申請方法（フラグメントページ）

 

• パラメータinnodb_file_per_tableが有効になっている場合、作成されるテーブルのデフォルトサイズは96KBです。しかし、1つの領域が1MBを占めることがわかっているのに、なぜその後96KBになるのでしょうか。

1. これは、各セグメントの先頭で、32ページサイズのフラグメント化されたページがデータの格納に使用され、これらのページが使用された後、 64の連続したページが適用されるためです。
2. これの目的は次のとおりです。一部の小さなテーブル、または元に戻すなどのセグメントの場合、最初に適用するスペースを減らして、ディスク容量のオーバーヘッドを節約できます。

地区申請のデモ事例

 

• 以下は、InnoDBが地区にどのように適用されるかを示す小さな例です。

1. 最初のステップ：t1テーブルを作成し、col2フィールドをVARCHAR（7000）に設定して、ページが最大2つのレコードを格納できるようにします（ページのサイズは16KB * 1024 = 16384ビットであるため）。次に、lsコマンドを使用して、表スペースのデフォルトのサイズが96KBであることを確認します。

1. ステップ2：次に、2つのSQLステートメントを表に挿入し、表スペースのサイズをチェックして、スペースが増加していないことを確認します。2つのレコードは同じページに配置する必要があります。

 

1. 3番目のステップ：この時点で、上記のツールを使用して表スペースを表示します。
2. ページオフセットが3のページ：これはデータページです
3. ページレベル：インデックスレベルを示し、0はリーフノードを示します。現在のすべてのレコードが1ページにあるため、リーフ以外のノードはありません

ステップ4：別のレコードを挿入すると、非リーフノードが生成されます。
ページレベル：この時点で、ページオフセットが3のページのページレベルが0から1に変更されましたが、新しく挿入されたレコードが原因です。 B +ツリー分割操作ですが、このページのタイプは引き続きBツリーノードです

ステップ5：上記と同じ操作に従って、さらに60レコードを挿入します。これは、現在のテーブルt1に63レコードと32ページがあることを意味します。インポートの便宜のために、
63個のデータをインポートした後でも、表スペースのサイズは1MB未満であることがわかります。つまり、データ・スペースのアプリケーションは、64個の連続したページ領域ではなく断片化されたページを通過します。

ステップ6：テーブルスペースファイルを再度確認すると、合計33個のBツリーノードがあることがわかります。ページレベルが1の非リーフノードページを除いて、ページレベルが0の合計32ページがあります。つまり、データベースにはすでに32のフラグメント化されたページがあります。ユーザーが再度スペースを申請すると、連続する64ページのサイズに応じて表スペースが増加し始めます。

ステップ7：レコードの挿入を続行してから、表スペースのサイズを確認します。32の断片化されたページが使い果たされたため、新しいページは地区ごとにスペースを申請します。

ステップ8：テーブルスペースファイルを再度分析します

 

5、表スペースの「ページ」

 

• ページはブロックと呼ばれることもあります
• ページはInnoDBディスク管理の最小単位です

innodb_page_sizeパラメーター

 

• InnoDBストレージエンジンでは、各ページのデフォルトサイズは16KBです。
• InnoDB 1.2.x以降、ページサイズはinnodb_page_sizeを介して4K、8K、または16Kに設定できます。設定が完了すると、すべてのページのサイズはinnodb_page_sizeになり、再度変更することはできません。mysqldumpのインポートおよびエクスポート操作によって新しいライブラリが生成されない限り

InnoDBでは、一般的なページタイプは次のとおりです。

 

• データページ（Bツリーノード）
• undo页（undo Log Page）
• システムページ
• 取引データページ（取引システムページ）
• バッファビットマップページの挿入
• バッファフリーリストの挿入ページ（バッファフリーリストの挿入）
• 非圧縮BLOBページ
• 圧縮されたBLOBページ

六、OK

 

• InnoDBストレージエンジンは行指向です。つまり、データは行に格納されます。各ページに保存されるレコードも厳密に定義されており、最大16KB / 2-200行のレコード、つまり7992行のレコードを保存できます。
• ここで説明する行指向のデータベース、つまり列指向のデータベースがあります
• MySQL infobrightストレージエンジンはデータを列に格納します。これは、データウェアハウスでの分析SQLステートメントの実行とデータ圧縮に非常に役立ちます。同様のデータベースには、Sybase IQ、GoogleBigTableが含まれます