誰もが8123バイトで十分

今日、MyISAMテーブルからInnoDBへの1つのサイトの転送中に、後者が1つの興味深い機能を明らかにしました。 2つのテーブルのエンジンを変更する要求は、奇妙なエラー「ストレージエンジンからのエラー139を取得」を返しました。 このトピックに関する情報を検索した後、テーブルの行がMySQLが動作するメモリページの半分に収まらない場合、このエラーが発生することがわかりました。 これらのページは16 Kbであり、半分、つまり8 Kbです。



制限自体はかなり奇妙ですが、一見すると、MySQLはテーブル行とは別のストレージにテキストデータを保存するため、達成するのは難しいようです。 これは半分しか真実ではないことが判明しました。 実際、InnoDBは「余剰」のみを個別のストレージに保存しますが、そこには各テキストフィールドの最初の768バイトは含まれません。 つまり テキストは、行の長さから、含まれるバイト数だけを食いつぶしますが、最大768バイトです。1つのテーブルに安全に保存できる長さ768バイトのテキストフィールドの最大数は10であると簡単に計算できます。スムーズに行きます。 しかし、フィールドの数を少なくとも1つ増やすことは価値があり、最初と同じエラーが発生します。



最も顕著なのは、制約の不条理、または文字列データ型の「大食い」でさえありませんが、この問題の沈黙です。 InnoDBを使用すると、数百のテキストフィールドを持つテーブルを簡単に作成できます。 同時に、テーブルに実際のデータを入力するときに、本番環境でのみ使用することはできません。 不明瞭なエラーメッセージは、肯定的な感情もほとんど残しません。



病気に対処するには2つの方法があります。



UNIV_PAGE_SIZEを増やして再コンパイルします（ 続き ）。



Barracudaファイル形式をサポートするプラグインを介してInnoDBを接続し 、テーブルのROW_FORMATをDYNAMICに変更します。 または、既にMySQL 5.5を使用している場合は、ROW_FORMAT = DYNAMICを使用します。