質問

Myisamがテーブルに可変長さの列(Varchar、Blob)を持っているため、クエリが非常に遅くなったため、Varchar列を別々のテーブルに移動するようにネットでアドバイスに遭遇しました。

それはまだInnodbの問題ですか?多くのVarchar行をテーブルに導入すると、ページが分割される場合はありません。たとえば、post_text(テーブルのシングルブロブフィールド)を別のテーブルに移動して、Innodbについてパフォーマンスを繰り返したと考えるべきですか?

役に立ちましたか?

解決

私が知っている限り、ブロブ(およびテキスト)は実際にテーブルの外側に保存されていますが、Varcharsはテーブルに保存されます。

Varcharsは読み取りパフォーマンスに悪いことです。これは、各レコードが長さがさまざまであり、レコード内のフィールドを見つけるのがコストがかかるためです。値を個別にフェッチする必要があり、ディスクまたはキャッシュからの別の読み取りが必要になるため、ブロブは遅いです。

私の知る限り、Innodbはこの点で違うことは何もしないので、パフォーマンスの特性が当てはまると仮定します。

Blob値の移動は本当に役立つとは思わない - 関係なくパフォーマンスにプラスの影響を与える全体的なテーブルサイズを縮小する以外に。 Varcharsは別の話です。あなたは間違いなくここで利益を得るでしょう。すべての列が定義された長さである場合(そして、それはあなたもブロブを使用できないことを意味すると思いますか?)、フィールドルックアップはより速くなります。

VarhcarとBlobのフィールドを「読んでいる」だけなら、これはショットの価値があると思います。ただし、選択したクエリがVarcharまたはBlobからの値を比較する必要がある場合は、かなり酸っぱくなります。

したがって、ここでは間違いなくパフォーマンスを得ることができますが、実際にパフォーマンスを獲得していること、そして増加は積極的な非正規化に値することをテストしてください。

Varcharの読み取りパフォーマンスを「最適化」する別の方法は、単に(固定長の)charフィールドに置き換えることです。ディスクスペースの増加が許容できる限り、これは読み取りパフォーマンスに役立つ可能性があります。

他のヒント

INNODBデータはMyisamとはまったく異なります。

myisamでは、すべてのインデックス(プリマリーまたはその他)がmyiファイルに保存されます。MyDファイルに保存されているデータへのポインターが含まれています。可変長さの行はクエリ速度に直接直接影響するべきではありませんが、mydファイルは、次に挿入する行に行を削除すると必ずしも削除されることはできないため、変数の長さの行でより断片化する傾向があります。変数の長さの値を更新して長くすると、他の場所に移動する必要がある場合があります。つまり、時間の経過とともにインデックスに関してオーダーが外れている傾向があり、範囲クエリが遅くなります。 (シーク時間が重要なスピニングディスクで実行している場合)。

INNODBは、プライマリキーのBツリーのページにクラスター化されたデータを保存します。データがページに適合する限り、BLOBを使用しているかVarcharを使用しているかどうかにかかわらず、ページに保存されます。定期的に長い値を誤って挿入しようとしていない限り、あなたの行が固定された長さであるか、可変長であるかは関係ありません。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top