どのように実際のMySQL DBサイズを照会するのですか？

Question

私は大きなSQLテーブルを持っています、約30 GB、私はそれの約半分を削除しました。 information_schemaには正しい情報が保持されていません（DBが最適化されるまで）。 実際のサイズを取得する方法はありますか？フルテーブルスキャンを使用して？

Answer 1

InnoDBでは、多くの数字はむしろあいまいです。 1行のサイズは実際には利用できません。 SHOW TABLE STATUS（およびinformation_schemaに相当するプローブ）は、の見積もりを提供します。しかし、その見積もりは大幅にオフになることがあります。時には、2倍以上の高さまたは低い場合もあります。

ここでは、InnoDBのテーブルレイアウトの概要を説明します。

データは、PRIMARY KEYで注文された16KBブロックのBTreeに格納されます。 （他のBTreeにあるセカンダリインデックスは議論しません）

このような構造に行を挿入すると、目的のブロックに空きがあるか、ブロック分割が必要になることがあります。行を削除すると、おそらくブロックの一部が解放され、ブロックを「空き領域」に返すことはほとんどありません。

"avg_row_length"は、ディスク領域から "空き"ブロックを差し引いた後、行数で割ったものとして計算されます。

しかし、それは別のファジー番号になります。行の数は、ブロックごとにいくつの行があるかを確認してから、いくつかの計算を行うために、BTreeにいくつかのプローブを作成することによって推定されます。

次に、行の長さは、ファジー・ディスク・スペース（各ブロックの空きスペースを考慮しない）をファジー・ロー・カウントで割ったものです。

私は「Data_free」と言いました。しかし、ブロックの数を変更しないときに行を挿入/削除すると、ではなく、がData_freeに変更されます。

TEXT（いくつかの警告、条件、例外を含む）列は、別々のブロックに格納されます。割り当て単位には16KBのブロックがあります。したがって、TEXTまたはBLOBの列がある場合、計算が本当に乱雑になります。

小さなテーブルには16KBのブロックがいくつか割り当てられていますが、それらが小さくても小さくなると、一度に8MBのスペースが割り当てられます。ここでも、Data_freeにこれを見ることができます。多くはできません。 OSに解放

• "DATA_FREE" で可視ではなく：

  "空き" スペースは、3つのカテゴリーに入っています。

• ブロックで再利用可能な領域は、UPDATEsとINSERTsが発生します。
• 見えないオーバーヘッド。各行の各列の長さを取ることによって、集計するテーブルのスペースの2〜3倍を計画します。

申し訳ありませんが、あなたには不正確な番号が付いています。

トピックを変更しています...なぜ大きな削除を行っていますか？スライドタイムスケール（ニュース：think）をお持ちの場合は、PARTITIONsが優れています。すべてのデータを置き換える場合は、RENAME TABLEのトリックが気になります。