AVG行の長さが予想の4倍になるのはなぜですか？

平均行サイズが大きくなる理由はたくさんあります。

• 概算です。 （通常、高さは2x〜3xであることがわかりました。）極端な場合、テーブルの1行で、1行あたり16384バイトを要求します。これは1つのInnoDBブロックです。テーブルの行数は推定です。 。行に使用されるディスク容量は正確ですが、以下のオーバーヘッドを参照してください。平均行サイズは、これら2つの商です。

• 列ごとのオーバーヘッド-1または2バイト

• 行あたりのオーバーヘッド-20〜30バイト-トランザクションの処理、ブロック内の行の検索などに使用します

• ブロックあたりのオーバーヘッド-16KBブロックあたりのバイト数

• BTreeでのスラッシングのオーバーヘッド-最小はブロックの約1/16、最大はブロックの約半分、平均は大量の削除やランダムな挿入後の約30％です。

• ディスクスペースのチャンクを事前に割り当てるためのオーバーヘッド（1MB？8MB？）

• テーブルが1つのブロックに収まるようになると、レイアウトアルゴリズムがシフトし、オーバーヘッドの割合が一時的に急上昇します。

• 削除された行はOSにスペースを返さないため、ファイルサイズは一定に保たれ、それによって見かけのが増加します。 行サイズ。

• 明示的なPRIMARY KEYがない場合 またはUNIQUE PKにプロモートできるキーの場合、PK用のアクセスできない6バイトのフィールド（行ごと）があります。

• 大きなTEXT / BLOB さらにVARCHAR 「オフレコ」で保存されます。これは計算を非常に複雑にします。そして、それは4つのROW_FORMATsのどれに依存します 使用しています。場合によっては、そのようなセルごとに20バイトの「ポインタ」があります。

• FOREIGN KEY 制約は、 可能性がある場合を除いて、必要なスペースに追加されません。 インデックスの作成を強制します。

• INDEXes 、PRIMARY KEY以外 avg_row_lengthには含まれていません。

• PRIMARY KEY 通常 データのオーバーヘッドはごくわずかです。 BTree。単純な経験則は、1％のオーバーヘッド（列自体の上）です。このオーバーヘッドは、BTreeの非リーフノードです。

• InnoDBトランザクションがビジーである間、変更された行はすべて「履歴リスト」に保持されます。これにより、オーバーヘッドが増加します。

• （完全に関連しているわけではありません）。 InnoDBのCOMPRESSED 問題があります。通常の3倍のテキスト圧縮とは異なり、約2倍の圧縮しか得られません。圧縮されたデータと圧縮されていないデータの両方を同時にbuffer_poolに含める必要があるため（少なくともいくつかのブロックについて）、RAMがいくらか必要になります。

SHOW TABLE STATUS information_schema.TABLESから取得します 同じデータを提供します。 いくつかを取得する方法があります データと各テーブルのB+ツリーの深さに関する洞察。