木下と申します。

（同姓ですね）木下さん早速のお返事ありがとうございます。

On Thu, 24 Jan 2008 12:39:24 +0900
Yasufumi Kinoshita <kinoshita.yasufumi@xxxxxxxxxx> wrote:

> InnoDBにおける表の構造は主キーの索引構造になっていますので、
> ランダムな順番での挿入はフラグメンテーションが多発してしまい、
> Data_lengthは無用に大きくなってしまいます。

はい、確かにそのようです。
試しに、主キーをシーケンシャルに並べた256万レコードのINSERTと
ランダムに並べた256万レコードのINSERTでは、（そのランダム性にも
よると思いますが）おおよそ、1.6倍程度のData_lengthになりました。

> ALTER TABLE test ENGINE=InnoDB;
> ANALYZE TABLE test;
> とデフラグすると、SHOW TABLE STATUSの結果が変わりませんか？

そして、主キーをランダムに並べた256万レコードをINSERTしたテーブルに
対して、ALTER TABLEを実行すると、シーケンシャルに並べた256万レコードを
INSERTしたテーブルのData_lengthと同じ値になりました。

シーケンシャルの方が「詰まった配置」で書き込まれる、つまり、
一番少ない容量のテーブルサイズになると解釈しました。

> また、必要容量計算ですが、
> このように表自体が索引の構造なので、厳密に正確にサイズを見積もるのは難しいです。

UNDOログに相当する領域が必要であることと、
また、索引構造（InnoDBはB-Treeでしたよね？）のため、
厳密な計算が難しいというのも理解はできるのですが、
結局のところ、MySQLでInnoDBを用いた場合に、
必要なディスク容量を見積もるための「指針」というか「拠り所」は
ないものでしょうか？

現在担当しているシステムは、ディスク容量にシビアなシステムという
制約がありまして、「気にならないくらい大容量のパーティションを割り当てて
おけばいい」というわけにもいかず、困っております。

レコードの挿入の度にALTER TABLEを発行するのも性能に影響しそうですし、
何らか「これを越えない」といった計算はないものでしょうか？
あるいは、そういうコンサルテーションを受けることができる
専門家はおられませんでしょうか？

皆さんはどうされておられますか？

--
S.Kinoshita
shige_chan@xxxxxxxxxx