こんばんは、平塚です。

On Mon, 16 Jan 2012 14:29:30 +0900
山田　希 <Yamada_Nozomu@xxxxxxxxxx> wrote:

> ■質問内容
> １．Barracudaフォーマットには項目数等に制限があるのでしょうか？
> 　　制限がある場合、回避する方法はありますでしょうか？

MySQL本体には4,096カラムまでという制限があって、
InnoDBには1,000カラムまでという制限があります。
ただし、InnoDBではレコード長にも制限が設けられています。

Barracudaフォーマットの場合、BLOBやTEXTのデータはページ外に格納され
ページ内には20バイトのポインタのみが格納されます。

InnoDBにはレコード長にページサイズの半分、約8KBの制限があります。
そのため20バイトのポインタなら約400個格納できるのですが、
諸々のオーバーヘッドがあって186個になっているのだと思います。
諸々のオーバーヘッドについてはすいません詳しくないです。

MySQLをコンパイルし直すことでInnoDBのページサイズを64KBまで
拡張できるそうです…が、私は事例を見たことがないです。

DB設計レベルでテーブルを縦に分割するのが、
よくある対処方法ではないかと思います。


> ２．１．の回避が難しい場合最初に出たエラー「Got error 139 from storage
> engine」
> 　　を回避する方法はありますでしょうか？

旧フォーマットの場合、BLOBやTEXTのデータは
先頭から768バイトまでがページ内に格納されます。
そのためBarracudaフォーマットのように186個も入らず、
10個が限界のはずです。

もう一つの違いとして、レコード長の制限に違反した場合、
BarracudaフォーマットはCREATE TABLEのときにエラーが返るが、
旧フォーマットは実際にINSERTしたときにエラーが返るというものが
あります。

「Got error 139 from storage engine」がINSERT時に出ているのは
この仕様のためで、これはそのようなテーブルを作成してしまった時点で
失敗ということで、残念ながらINSERT方法を工夫して回避できる類の
ものではありません。

==

方針として少しでも多くのカラムを格納したいのであれば、
ROW_FORMAT = DYNAMICで186カラム以内で作成し、溢れた分を
別テーブルに分割して格納、というのが良いと思います。

また、BarracudaのCOMPRESSEDで試していらっしゃいますが、
COMPRESSEDはかなり遅いので、特別の理由がなければ
DYNAMICの方が無難だと思います。

例示いただいたブログではSELECTの性能が落ちていない様子がありますが、
それはあくまで参照処理の場合であって、更新処理である
INSERT/DELETE/UPDATEはそれはもう大変なことになります。


よろしくお願いいたします。

-- 
平塚貞夫 hiratsuka.sadao@xxxxxxxxxx