0

単一のファイル構成 (/var 内) で InnoDB データベースを使用しているため、innodb_file_per_table はありません。

MySql ワークベンチで、データベースの使用スペースを照会すると、このクエリで

SELECT table_schema "Database", sum( data_length + index_length ) / 1024 / 1024 "Data     Base Size in MB" 
FROM information_schema.TABLES GROUP BY table_schema;

47 GB のデータがあると表示されます。ただし、ibdata1 のサイズは 99 GB です...

ibdata1 には、テーブル インデックス、MVCC (Multiversioning Concurrency Control) データ、テーブル メタデータなど、テーブル データ以外のものがたくさん含まれていることを知っています。

私の質問は次のとおりです。おそらく 52 GB の ibdata1 が medatada であり、他の多くのものであることは正常ですか? 通常、ibdata1 ファイルにはテーブル データ以外にどのくらいのデータを含める必要がありますか?

4

2 に答える 2

2

いいえ、それほど多くのメタデータがあるのは普通ではありません。を使用していない場合、ibdata ファイルが途方もないサイズに成長するのは普通のことですinnodb_file_per_table。

データベースが大きくなると、ibdata ファイルも大きくなりますが、実際に縮小することはありません。

たとえば、ある時点で 130 GB のデータがあり、その一部を削除した場合、データが削除された後も ibdata ファイルは 130 GB のままです。後続の挿入に使用する「空き領域」がたくさんあるだけです。

ファイルの圧縮に関しては、データベースを消去して復元する以外に実際にできることはあまりありません。この回答には、それを行う方法に関するいくつかの適切な指示があります。

Howto: mysql InnoDB ストレージ エンジンをクリーンアップしますか?

innodb_file_per_tableまた、テーブルからデータを削除し、後でそのテーブルを最適化することで、個々のテーブル ファイルのサイズを実際に縮小することを検討することもできます。

于 2013-01-07T15:36:55.970 に答える
2

ibdata1 に大量の「余分な」スペースがある理由はいくつかありますが、最も可能性の高いケースは次のとおりです。

  • 過去に大量のデータを削除しました。行を削除したりテーブルを削除したりすると、ファイルに空き領域ができますが、ファイル自体が縮小することはありません。
  • Undo ログ領域が多すぎる (または過去にあった) 可能性があります。DELETEおよび操作中に元に戻すログが保持されUPDATE、非常に長時間実行される操作の場合、多くの行に触れると非常に大きくなる可能性があります。繰り返しますが、このデータを保持するためにファイルが拡張された場合、ファイルが縮小することはありません。

前述のようinnodb_file_per_tableに、テーブルを定期的に削除することが予想され、ディスク容量を取り戻したい場合は、を使用するとこれに役立ちます。私のブログ投稿InnoDB スペース ファイル レイアウトの基本は、ファイルに何が含まれているかを理解するのに役立つ場合がありibdata1ます。

于 2013-01-07T21:17:17.577 に答える