mysqlのinformation_schema.tablesの解釈DATA_LENGTH、INDEX_DATA_LENGTH、およびDATA_FREE

Question

2時間のデータパージが原因で、mysqlインスタンスのデータ使用量がわずか32 KBに減少した理由を説明することができます。ここに私の詳細があります：

データをパージしようとしているmysqlデータベース（Amazon RDS上で動作しています）があります。私は、Amazonが1TBであなたを肩代わりさせるので、ストレージスペースが足りなくなるのを避けるためにこれをやっています。私たちが何もしなくても、この限界に達するでしょう。

私は私のテーブルとインデックスのサイズを計算するには、このコマンドを使用しています：

select * from information_schema.tables; 

私の記憶装置の大部分を消費し、特に2つのInnoDBテーブルがあります。私はレコードを削除する最大のテーブルを反復処理するプロセスを持っています。時間t = 0で私は上記のSQLクエリを実行し、データ長とインデックスデータの長さのために、以下の結果得た：

• データ長：56431116288
• インデックスのデータ長：74233151488

2時間を後に、継続的に私のデータベース・クリーナ・プロセスを実行した後、私は上記のSQL文を実行し、次のようだ：

• データ長：56431083520
• インデックスデータの長さ：74126147584

これは、基本的には、32KBのテーブルデータと102MBのインデックスデータを削ったことを意味します。

インデックスの縮小は意味があります。テーブルデータの削減は非常に小さいです。私のデータベースのバックアップコピーでこのテストを実行しているので、この時間に他のデータが挿入されている可能性はありません（RDSに関する素晴らしい点の1つは、DBの完全な複製を取得して実験を実行することができることですこのような）。また、AUTO_INCREMENTの値が両方とも同じであることを確認しました。

誰かがデータの長さがあまり動かなかった理由を説明できますか？データの長さは本当に素早く汚れた近似ですか？ mysqlが最終的に行う他のコンパクションのステップはありますか？あるいは、私はこれらのフィールドの使用を完全に誤解していますか？

ありがとうございました！

更新

私はそれを考え出したかもしれ

- 時間t = 0

• DATA_FREE = 77594624

4時間のlaters、

• DATA_FREEで= 256901120

つまり、DATA_FREEをappx 171MB増やしました。

したがって、別の171MBを挿入すると、DATA_FREEプールからデータが出てデータの長さが増えませんか？

別の言い方をすれば、新しいInnoDBテーブルから始めて20 GBのデータを挿入するとします（20 GBには余分なInnoDBが組み込まれていると仮定し、InnoDBに格納されたデータはMyISAMよりも大きいと認識します）すべてのデータを挿入したら、10 GBのデータを挿入します。私はinfo_schema.tablesからselect *を実行すると、10GBのデータ長と10GBのデータがないことがわかります。私は、30 GBのデータ長/ 0 GBのデータがないことを期待してはいけません.10 GBのデータ長/ 10 GBのデータがないとは思いませんか？

アップデートは2

This post on Stack Overflowも私の分析ことを確認するように見えるでしょう。

Answer 1

表の「データ長」には、表内に存在する空き領域が含まれます。テーブルをデフラグしてその領域を解放するには、テーブルをOPTIMIZEにする必要があります。これは、テーブルをしばらくロックしている可能性があることに注意してください。

InnoDBストレージエンジン（CREATE TABLE (...) ENGINE=InnoDB;）を使用すると、テーブルの最適化がほとんど不要になり、データベースの作成が一般的に高速化されます。既にそれを使用していない場合は、おそらく開始する必要があります。 :)