300列のテーブルがあります。各列は最大255バイトです(このためのisビジネス上の正当性があります)。
VARCHAR(255)
を使用して作成すると、最大バイト数の制限を超えてしまいます。だから私は300個のTEXT
フィールドを使用して作成しています。次にデータを挿入しようとすると、エラーが発生します。
行サイズが大きすぎます(> 8126)。
一部の列をTEXTまたはBLOBに変更するか、ROW_FORMAT = DYNAMICまたはROW_FORMAT = COMPRESSEDを使用すると役立つ場合があります。
現在の行形式では、768バイトのBLOBプレフィックスがインラインで格納されます。
これを読んだ後、ROW_FORMAT=COMPRESSED
を指定して、バラクーダ形式を使用するようにテーブルを変更しようとしました。この問題は、その形式を使用してテーブルを作成しようとすると、同じエラーが発生するようです。
CREATE TABLE T_ObjLarge__c (Id VARCHAR(18), Name VARCHAR(80),
ObjLarge_Field_1__c TEXT,
ObjLarge_Field_2__c TEXT,
...
ObjLarge_Field_300__c TEXT
) ROW_FORMAT=COMPRESSED ;
私が得るエラーは:
行サイズが大きすぎます(> 8126)。
一部の列をTEXTまたはBLOBに変更すると役立つ場合があります。
現在の行形式では、0バイトのBLOBプレフィックスがインラインで格納されます。
Linux mintでMySQL 5.5.31を使用しています。インデックスはありません。私はDYNAMIC
形式を試しました。同じように動作します。
SHOW GLOBAL VARIABLES LIKE 'innodb_file_per_table';
の出力:
+--------------------------+-----------+
| Variable_name | Value |
+--------------------------+-----------+
| innodb_file_format | Barracuda |
| innodb_file_format_check | ON |
| innodb_file_format_max | Barracuda |
| innodb_file_per_table | ON |
+--------------------------+-----------+
InnoDBの現在の制限を超えているというだけの理由で、これは非常に難しい質問です。
あなたの質問は決してユニークではありません。これは以前にここで扱われました
また、現在使用している文字セットも調べます。
ビル・カーウィンは最後の段落でそれを最もよく言った
また、適切に設計されたテーブルが行サイズの制限を超えるのを見たことがないこともコメントしなければなりません。 First Normal Formの繰り返しグループの条件に違反しているのは、強い「コードのにおい」です。
より良いデザインを定義する必要があります。それを正当化できるビジネス上の理由はありません。どうして?
2011年7月20日、私はこの質問に答えました: MySQLの列が多すぎます
私は個人的にこれを目撃しました
開発者としての私は、1995年にDB2がメインのRDBMSだった会社で働いていました。同社には、270列、数十のインデックスを持つ単一のテーブルがあり、データの取得でパフォーマンスの問題がありました。彼らはIBMに連絡し、コンサルタントにこの1つのモノリシックテーブルを含むシステムのアーキテクチャを調べてもらいました。 「今後2年間でこのテーブルを正規化しないと、DB2はStage2処理を実行するクエリ(インデックス付けされていない列でのソートが必要なクエリ)で失敗します。」これは、数兆ドル規模の企業に270列のテーブルを正規化するように指示されました。さらに2000列のテーブルです。
300のTEXT列を持つテーブルは、同じ種類の問題を求めています。
[〜#〜]要約[〜#〜]:ビルカーウィンが前に言ったので、同意します。それは確かに行の長さの問題を回避します。
設計が正当化されない可能性があることに同意します...しかし、バラクーダ形式では、ページ上のTEXT
またはBLOB
列のプレフィックスを保存しないことでこれを許可する必要があります。
ドキュメントによると、TEXT
列は行に10バイトのスペースしか必要ないため、300 = 3000バイトです。 OPからの追加情報を除いて、私はこれがバグであるか、ドキュメントが間違っているかあいまいである場合であると考える傾向があります。
また、これはBLOB
にのみ当てはまり、TEXT
には当てはまらない場合もありますが、ほとんどの場合、ドキュメントにより、Barracudaでも同等に扱われていると信じられます。
自分の利益のために好奇心が強いので、私はこれを複製しました。 MySQL 5.5.32では、INT
PKと最大186のNULL可能TEXT
またはでテーブルを作成できますBLOB
列ですが、187個以上のTEXT
またはBLOB
列を定義しようとすると、OPと同じエラーが発生します。
さらなるテストでは、各TEXT
列に約43行のバイト(利用可能な〜8126のバイト)が使用されていることを示唆しています。ドキュメントに基づいて予想されるよりも早く到達する。