MySQL-3行レコードのストレージ構造

MySQL-3行レコードのストレージ構造
本文は同様に子供の書いた《MySQLはどのように運行したのです:根本的にMySQLを理解します》を参考にします
下位層に記録されたストレージロジックがどのようなものかをまとめます.
InnoDBページの概要
このストレージエンジンは、テーブルのデータをディスクに格納し、本格的なデータ処理はメモリに格納されます.innodb ， ， 16KB.
行書式
行のフォーマットを指定します.

CREATE TABLE    (    ) ROW_FORMAT=     
    
ALTER TABLE    ROW_FORMAT=     

compact行フォーマット
1つの完全な記録は、 と に分けることができる.
一、記録された追加情報
Yesサーバは のために、変長フィールド長リスト、null値リスト、レコードヘッダ情報に分けられる.
長いフィールド長リスト
変長フィールドのデータ型は、varchar(M)各種textタイプ、各種blobタイプなどであり、この変長フィールドにどれだけのバイトが格納されるかは固定されていないため、変長フィールドの記憶空間は2つの部分に分けられる:真のデータコンテンツ+占有バイト数.

compact行フォーマットでは、 を長尺化フィールド長リストとして形成し、各長尺化フィールドデータが占有するバイト数 とする.

バイト選択記憶方式:可変フィールドが記憶する最大バイト数W*Mが255を超え、実際に記憶するバイト数が127バイトを超えることを許可する場合、2バイトを使用し、そうでなければ1バイトを使用する.

は、値がNULL以外のカラムコンテンツが占有する長さのみを格納し、値がNULLのカラムの長さは格納しません.

は、すべてのレコードにこの変長フィールド長リストがあるわけではありません.たとえば、テーブル内のすべてのカラムが変長データ型ではない場合、この部分は必要ありません.

NULL値リスト
テーブル内のカラムの中にはNULL値が格納されているものもあり、記録された実際のデータに格納されている場合は場所を占めているため、null値リストに格納され、処理手順は次のとおりです.

1.まず、nullを格納できるカラムの統計を行います.

2.テーブルにnullを格納できるカラムがない場合、null値リストも存在しません.そうでなければnullを格納できるカラムごとにバイナリビットが対応し、バイナリビットはカラムの順序で逆順序に並べられ、値が1の場合はカラムの値がnull、値が0の場合はnullではありません.

3.整数バイトのビットで表す必要があります.整数バイトでない場合は、バイトの上位に0を加算します.類推では,nullが9個許可されている場合,2バイトで表す必要がある.

レコードヘッド情報
固定された5バイト、すなわち40バイナリビットであり、異なるビットは、そのレコードが削除されたか否か、保有しているレコード数など、異なる意味を表す.

delete_maskタグこのレコードが削除されたかどうか

min_rec_mask,B+ツリーの各層の非葉ノードの最小レコードにこのタグ

が追加される.

n_owned、4ビットを占め、現在の記録が持つ記録数

heap_No,13ビットを占め、現在記録スタックに記録する位置情報

record_type、3ビットを占め、現在の記録のタイプ、0通常記録、1 B+ツリー非葉ノード、2最小記録、3最大記録

next_レコード、16ビットを占め、次のレコードの相対位置

delete_maskは、このレコードが削除されたか否かをマークするために用いられる.削除レコードは他のレコードをディスクに並べ替えるので、削除マークをつけるだけである.これらの削除レコードはいわゆるゴミチェーンテーブルを構成し、このチェーンテーブルに記録する占有スペースを再利用可能な空き間と呼び、その後、新しいレコードがテーブルに挿入されると、削除されたレコードが占有するストレージ領域を上書きする可能性があります.heap_Noは、現在このページに記録されている場所を示します.innodbは、 ごとに2つのレコードを自動的に追加します. または と呼ばれます.1つは最小レコードを表し、1つは最大レコードを表します.(完全なレコードの場合、比較レコードサイズは比較プライマリ・キーのサイズです).
record_type
next_recordは、現在記録されている真実データから次の記録された真実データのアドレスオフセット量を導く.次のレコードとは、プライマリキーの値が小さい順の次のレコードで、
Infimumすなわち最小レコードを規定する次のレコードが、本ページで主キー値が最小のユーザレコードであり、本ページで主キー値が最大のユーザレコードの次のレコードがSupremumである最大レコードである.ポインタは、次のレコードのレコードヘッダ情報と実際のデータとの間の位置を指します.この位置は、左に読み取るのがレコードヘッダ情報で、右に読み取るのが実際のデータです.これにより、キャッシュのヒット率が向上する可能性があります(フィールドとフィールド長情報のメモリ内の距離がより近い).
innodbは、削除されたレコードに対して、再挿入時にこのストレージ領域を再利用します.
二、記録された真実データ
MySQLでは、レコードごとにデフォルトのカラム(非表示カラム)が追加されます.
innodbテーブルのプライマリ・キーの生成ポリシー:ユーザー定義プライマリ・キーを優先し、プライマリ・キーとしてUniqueキーを選択しない場合、innodbはテーブルのデフォルトにrow_という名前を追加します.idの非表示列をプライマリキーとして使用します.
char(M)カラムの格納フォーマットcharタイプのカラムでは、カラムが一定長文字セットを使用している場合、カラムが使用するバイト数は、変長フィールド長リストには加算されず、変長文字セットを使用する場合、そのカラムが使用するバイト数も変長フィールド長リストに加算されます.
ラインオーバーフロー
varcharタイプのカラムには最大65535バイト、レコードの追加情報を差し引くと65532バイト、異なる文字セットに対して65532/3の文字が格納されます.
compactおよびReduntant行フォーマットでは、記憶領域が非常に大きい列については、記録された真のデータはその列の上位768バイトしか記憶されず、残りのデータをいくつかの他のページに分散して記憶し、これらのページを指すアドレスを20バイトで記憶し、残りのデータが存在するページを見つけ、これらの残りのデータを と呼ぶ.これらのページを格納 という.
DynamicおよびCompressed行フォーマット
compact行フォーマットとの違いは、すべてのバイトを他のページに格納し、実際のデータを記録する場所にのみ他のページのアドレスを格納することです.
posted @
2019-05-09 19:00 yeevan読書(
...) コメント(
...) コレクションの編集