5

MySQLtextでラージの代わりに型を使用する場合の比較、個人的な経験、またはガイドラインはありますか?varchar

私のデータベースのほとんどのエントリは 1000 文字未満ですが、中には 4000 文字以上かかるものもあります。より良いバリアントvarcharを作る限界の長さはどれくらいですか?text

これらのフィールドにインデックスを付ける必要はありません。

4

2 に答える 2

5

私は個人的な経験はありませんが、この男は：

VARCHAR と TEXT - いくつかのパフォーマンス数値

簡単な答え: varchar はかなり高速でした。

編集- いいえ、そうではありませんでした。彼は別の方法でインデックスを作成していました。varchar には完全なインデックス (255 文字) がありましたが、テキストには 255 文字のプレフィックス インデックスがありました。彼がそれを取り除いたとき、彼らは多かれ少なかれ同じことをしました.

スレッドの後半には、次の興味深い情報があります。

SELECT に tmp テーブルが必要な場合、最初の選択肢は MEMORY を使用することです。これは RAM のみであるため、おそらく著しく高速です。（第二候補は MyISAM です。）ただし、MEMORY では TEXT と BLOB は許可されていないため、使用できません。(MEMORY をスキップする理由は他にもあります。)

編集 2 - より関連性の高い情報。今回は、さまざまなインデックスがさまざまなタイプを処理する方法を比較します。

MyISAM は TEXT と BLOB を「インライン」にします。テーブルを検索している場合（範囲スキャン/テーブルスキャン）、「牛の水田をまたいでいる」ことになり、ディスク I/O にコストがかかります。つまり、この場合、インライン BLOB が存在するとパフォーマンスが低下します。

InnoDB は TEXT または BLOB の 767 バイトのみをインラインに配置し、残りは他のブロックに入ります。これは、パフォーマンスを向上させる場合もあれば、パフォーマンスを低下させる場合もあります。

他の何か (Maria? Falcon? InnoDB プラグイン?) は、TEXT と BLOB を完全に別の場所に置きます。これにより、VARCHAR と比較すると、パフォーマンスに顕著な違いが生じます。TEXT の方が高速な場合もあります (たとえば、ブロブを必要としない範囲スキャン)。場合によっては、VARCHAR の方が高速になることがあります (たとえば、それを調べたり、返したりする必要がある場合)。

于 2010-01-07T00:47:59.720 に答える
1

もちろん、知るための最善の方法は、実際のデータセット、または少なくともシミュレートされた同等のものを使用して、自分でいくつかのテストを実行することです。いくつかのスクリプトを記述してデータを入力し、選択を実行するだけです。さまざまなサイズの varchar、次にテキストでテストし、タイミングと全体的なシステム使用率 (CPU/負荷、メモリ、ディスク i/o) の両方を測定します。

これが問題になるほどの負荷がかかる場合は、とにかく自動テストを行う必要があります。

于 2010-01-07T01:14:46.150 に答える