2012年1月16日

[mysql 15657] Re: BarracudaフォーマットのTEXT型項目数制限について

こんばんは、平塚です。

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

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


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

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

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

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

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


> 2.1.の回避が難しい場合最初に出たエラー「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@xxxxx


投稿者 xml-rpc : 2012年1月16日 18:05
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/108137
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。