2016-11-21 7 views
-1

誰かが実際のデータサイズとの関係でmySQLテーブルサイズを明らかにすることができますか?特に、テーブルサイズを「意味がある」ものにする方法はありますか?mySQLテーブル:ファイルサイズを合理的かつ合理的にするにはどうすればよいですか?

私は14のフィールドを持つ単純なテーブル定義を持っています。整数と浮動小数点型が混在するすべての数値、合計レコードサイズ= 48バイト、1つの整数インデックスフィールド。

例:LOAD DATA INFILEを使用して5つの表をロードします。レコード数は22,000〜37,000の範囲で、データの合計バイト数は1.3〜1.8MBです。テーブルサイズは、9.2MBの最小サイズを除き、すべて10.24MBです。これは気違いではないですか?実際のデータを超えるファイルサイズのオーバーヘッドはあるものの、500%を超えるとわかっていますか?

+0

どのテーブルエンジンを使用していますか?以前のデータがテーブルにありましたか?以前のデータをテーブルから削除しましたか? – Shadow

+0

これらは新しく作成されたテーブルです。それらに対して実行される唯一の操作は、LOAD DATA INFILEです。あなたは "テーブルエンジン"が何を意味するか分かりませんが、私はVBAでADOを使ってSQLを実行しています...しかし、私はmySQLコマンドラインを使って同じ結果を得ています。 – dts

+0

テーブルenginse:innodb、myisamなど各ストアデータは、それぞれ異なる設定オプションがあります。 – Shadow

答えて

0

Innodbは、データファイルの断片化を減らすために、データファイルの拡張が必要な​​ときに大きなブロックのデータを予約し、インデックスもテーブルスペース内に保存します。 innodb file space managementのmysqlドキュメントによると、

各テーブルスペースはデータベースページで構成されています。 MySQLインスタンスの各テーブルスペースは、同じページサイズを持ちます。デフォルトでは、すべての表領域 のページ・サイズは16KBです。 MySQL インスタンスを作成するときにinnodb_page_sizeオプションを指定することにより、ページサイズを8KBまたは4KB に減らすことができます。 MySQL 5.7.6以降では、ページサイズを 32KBまたは64KBに増やすこともできます。詳細は、innodb_page_size のマニュアルを参照してください。

このページは、 サイズ(64連続16KBページ、または128 8KBページ、または256 4 KBページ)のサイズで最大16KBのページのサイズが1MBにグループ化されています。 ページ・サイズが32KBの場合、エクステント・サイズは2MBです。ページサイズが64KBの場合、エクステントサイズは です。サイズは4MBです。テーブルスペース内の "ファイル"は、InnoDBの セグメントと呼ばれます。

セグメントがテーブルスペース内で大きくなると、InnoDBは最初に の32ページを1つずつ割り当てます(このセグメントは、実際には多くの表領域セグメントを含むロールバック セグメントとは異なります)。その後、InnoDBはセグメント全体に のエクステントを割り当て始めます。 InnoDBは、一度に最大4つのエクステントを追加して、データの順性を確実にするために大きなセグメントに を追加できます。

InnoDBのインデックスごとに2つのセグメントが割り当てられます。 1つは のBツリーの非リーフノード用で、もう1つはリーフノード用です。 をディスク上で連続しておくと、これらのリーフノードに実際のテーブルデータが含まれているため、より効率的なシーケンシャルI/O操作が可能になります( )。

+0

私は以前にそのページを見たと思います。今回私はそれを2度読んで、すべてのリンクをたどった。私はそれが私に何を伝えているのかまだ分かりません。私はエクステントが最初に追加されたときに空のオーバーヘッドがあることを理解していますが、ここでは空のスペースは特定のテーブルに対して1エクステントを超えていないようです...このような場合、エクステントのサイズは変わらないので、ページサイズをデフォルトの16kから8kまたは4kに減らすことは効果がありません。 基本的に、私はまだ何かが欠けていると思います...テーブルが常に実際のデータの> 500%のサイズであれば、誰もmySQLを真剣に受け止めませんでしたか? – dts

+0

私はあなたがもう一度読むべきだと思います: "InnoDBはデータの順性を確実にするために、一度に** 4エクステントまで**大きなセグメントに追加することができます"。そして、なぜinnodbがこれを行うのかという根拠を絶対に無視しました。ファイルが断片化していないことを確認することです。あなたが忘れている最後の薄いものは、あなたのテーブルが非常に小さいということです。したがって、innodbがファイルサイズを4MBとすると、それは大きな違いに見えます。数GBのテーブルをお持ちの場合は、さらに4MBのスペースがレーダーに登録されません。 – Shadow

+0

しかし、4つのエクステントはまだまだ4MBですが、これらのファイルの膨大な容量よりもはるかに小さいですが、もっと大きなテーブルを試してみましょう。私は同じテーブル定義を使用して、さらにレコードを追加しています:35MBのデータを持つテーブルの場合、テーブルサイズは66MB = 90%のオーバーヘッドです。 175MBのデータを持つテーブルの場合、テーブルのサイズは287MB = 64%のオーバーヘッドです。定性的に言えば、状況は悪い/愚か/奇妙に思える。どうしたの? – dts

関連する問題