著者：ワシ日：2014年3月14日Eメール：[email protected]
レコード内のバイト数が16Kよりも大きいを占めている場合私たちは、ページが、この場合には、レコードを保持することができないことを意味し、それに対処する方法で、ページのInnoDBは16K（16×1024 = 16384バイト）で、知っているのmysql ？
この質問に答える前の実験をやってみましょう：
我々は2つの表T1およびT2を作成し、それぞれ、唯一の違いは、T1とT2は、フィールドbはVARCHAR（8094）であり、他方はVARCHAR（8095）であるということです、そして、我々はT1_test.sqlファイルが含まれていますそこ10Wライン「T1値への挿入（1リピート（ 『』、8094））;」条SQL文、我々はテーブルに4分24秒を要しました。
その後、我々は（T2.test.sqlも、SQL文と同様のライン10Wが含まれている）T2_test.sqlテーブルT2を導入し、9分58秒を費やして！
私たちは、ファイル・スペース占有の二つのテーブル（この例では、innodb_file_per_talbeを開きます）を見てみましょう。
表T1を見ることができ804M、T2テーブルスペースの1.9Gを占領し、空間的、時間的な違いは、以上の2倍高かったです。
なぜ、1文字の時間と空間差の違いはそれほど巨大なだろうか？ここでは、一緒にダウン解剖します。
InnoDBストレージエンジンでは、一部のデータは、それは一般的に、そのブロブが考えられる、と呼ばれる実際のデータ行オーバーフローデータページの記録外部に格納され、そのようなデータの大列の保管などのテキストは、データページに格納されます外。しかし、我々はブロブに加え、それを参照して上記の実験は、外部イメージ上のテキストこのような大規模なカラムは、VARCHARタイプは、オーバーフローライン方式がデータを格納するために使用されるであろうと思われます。
InnoDBストレージエンジンのインデックステーブルは、のみ、次のページを保存する場合ので、各ページには、（そうでない場合は、リンクされたリストにB +ツリーの意味を失った）少なくとも2つの行を持っているべきであると、B +ツリー構造であることが、組織化されています、次にInnoDBストレージエンジンが自動的に各ページは、2つの以上の行の最小値を格納することができるように、オーバーフローデータページの行を記録保存します。
T2ラインのオーバーフローが発生したレッツ・確認（氏Jiangcheng八尾では、ツールpy_innodb_page_info書いたツールのソースコードを取得するにはこちらをクリック）
明確下記の理由は、我々はまた、それぞれ、文字のフィールドbにより異なり、以下のように、この2つのテーブルのレコードを挿入することがT1_1とT2_1テーブルを作成します。
この時点で、我々はpy_innodb_page_infoツールによって状況T1_1テーブルを分析します
図は、T1_1テーブルは、我々は状況T2_1を見て、唯一のBツリーが含まれています示しています。
私たちは、より多くの「非圧縮BLOBページ」ページよりT2_1テーブルT1_1の表を参照してください、それがBLOBページで二つの記憶を、分割T2_1にレコードの数が表示されます。
ときにテーブル内のフィールドの合計サイズの実験では、我々は意図的に二つのフィールドを取って、一つは4バイトの整数であり、他のフィールドは、両方一緒にVARCHAR（8094）、すなわち8098である、と言うことです数が8098より大きい場合、すなわち、レコードが挿入され、それは、時間または空間であるかどうか、メモリの2ページに分割され大いに和以上のフィールドサイズ<= 8098および> 8098比較して、低減された興味のある読者は、試みることができる行います。
実験中、我々はノートにポイントが少ない255よりも、余分なVARCHARがレコード1バイトの実際の長さを記録する際に、多くのバリエーションが使用しているため、ときvarchar型255の2バイトによってより大きくなるということですデュレーションフィールドテスト、スペースを追加し、合計サイズに注意を払います。例えば： "テーブルA1作成（int型、BのVARCHAR（2000）、C VARCHAR（3000）、D VARCHAR（3090））;" 次に、閾値がある。この場合= 8090 + 3090 + 3000 + 2000年4、相対以来我々の実験は、上記の、この表つ以上のA1のVARCHARフィールドは、このように可変長フィールドを記録するために、追加の2 + 2 = 4バイトを必要とする、255よりも大きいです。
