テーブルに可変長の列 (varchar、blob) を持つ MyISAM を使用すると、クエリが非常に遅くなるため、ネット上で varchar 列を別のテーブルに移動するようにというアドバイスに遭遇しました。
それはまだ InnoDB の問題ですか? テーブルに多くの varchar 行を導入するとページ分割が発生するという意味ではありません。たとえば、post_text (テーブル内の単一の BLOB フィールド) を別のテーブルに移動することを検討する必要があるということですが、InnoDB のパフォーマンスに関して言えば?
InnoDBデータはMyISAMとはまったく異なります。
MyISAMでは、すべてのインデックス（プライマリまたはその他）がMYIファイルに保存され、MYDファイルに保存されているデータへのポインタが含まれています。可変長の行がクエリ速度に直接影響することはありませんが、行を削除したときに残された穴が、次に挿入する行に必ずしもファイルされないため、MYDファイルは可変長の行でより断片化される傾向があります。可変長の値を更新して長くする場合は、別の場所に移動する必要があります。つまり、時間の経過とともにインデックスの順序が乱れる傾向があり、範囲クエリが遅くなります。（シーク時間が重要な回転ディスクで実行している場合）。
InnoDBは、ページにクラスター化されたデータを主キーのBツリーに格納します。データがページに収まる限り、BLOBまたはVARCHARのどちらを使用していても、データはページに保存されます。過度に長い値を定期的に挿入しようとしない限り、行が固定長であるか可変長であるかは問題ではありません。
私が知る限り、BLOB (および TEXT) は実際にはテーブルの外に格納され、VARCHAR はテーブルに格納されます。
VARCHAR は、各レコードが可変長になる可能性があり、レコード内のフィールドを検索するコストが高くなるため、読み取りパフォーマンスが低下します。BLOB は、値を個別にフェッチする必要があり、ディスクまたはキャッシュからの別の読み取りが必要になる可能性が非常に高いため、低速です。
私の知る限り、InnoDB はこの点で何も変わらないので、パフォーマンス特性が維持されると思います。
BLOB 値を移動しても、パフォーマンスにプラスの影響を与えるテーブル全体のサイズを縮小する以外は、実際には役に立たないと思います。VARCHAR は別の話です。あなたは間違いなくここで利益を得るでしょう。すべての列の長さが定義されている場合 (つまり、BLOB も使用できないということですか?)、フィールドの検索は高速になります。
VARHCAR フィールドと BLOB フィールドを「読んでいる」だけなら、試してみる価値があると思います。しかし、選択クエリで VARCHAR または BLOB の値を比較する必要がある場合は、かなり面倒です。
したがって、ここで確実にパフォーマンスを向上させることができますが、実際にパフォーマンスが向上していること、およびその増加が積極的な非正規化に見合う価値があることを必ずテストしてください。
PS。
VARCHAR 読み取りパフォーマンスを「最適化」するもう 1 つの方法は、単純に (固定長の) CHAR フィールドに置き換えることです。これにより、ディスク容量の増加が許容できる限り、読み取りパフォーマンスが向上する可能性があります。