MySQL：VARCHARとTEXTが大きいですか？

MySQLには、ユーザー間のメッセージを記録するメッセージテーブルがあります。典型的なIDとメッセージタイプ（すべて整数タイプ）とは別に、実際のメッセージテキストをVARCHARまたはTEXTとして保存する必要があります。フロントエンドの制限を3000文字に設定しています。これは、メッセージがこれより長くDBに挿入されることはないことを意味します。

VARCHAR（3000）またはTEXTを使用する根拠はありますか？VARCHAR（3000）を記述するだけで、直感に反するようなものがあります。私はStack Overflowで他の同様の投稿をしましたが、このタイプの一般的なメッセージの格納に固有のビューを取得するのに適しています。

• TEXTそして、実際のストレージの場所へのポインタを持っているテーブルで、テーブルの外に格納するBLOB ことができます。それが格納される場所は、データサイズ、列サイズ、row_format、MySQLバージョンなど、多くの要素に依存します。

• VARCHARテーブルとインラインで格納されます。VARCHARサイズが妥当な場合は高速ですが、トレードオフはデータとハードウェアに依存するため、実際のシナリオをデータでベンチマークする必要があります。

ユーザー入力の長さを予測できますか？

VARCHAR（X）

ケース：ユーザー名、メール、国、件名、パスワード

---

テキスト

ケース：メッセージ、メール、コメント、書式付きテキスト、html、コード、画像、リンク

---

MEDIUMTEXT

ケース：大きなjson本文、短から中長の本、csv文字列

---

長いテキスト

事例：教科書、プログラム、長年のログファイル、ハリーポッターと炎の杯、科学研究の記録

ベストプラクティスを明確にするために：

1. ほとんどの場合、テキスト形式のメッセージはTEXTとして保存する必要があります（最終的に任意の長さになります）

2. 文字列属性はVARCHARとして格納する必要があります（宛先ユーザー名、件名など）。

フロントエンドの制限があるとのことで、そうでない場合は素晴らしいです。* grin *秘訣は、DBを、それに接続するアプリケーションとは別のものと考えることです。1つのアプリケーションがデータに制限を課すからといって、データが本質的に制限されるという意味ではありません。

3000文字を超えないようにするメッセージ自体についてはどうですか？これが任意のアプリケーション制約（テキストボックスなど）の場合TEXTは、データレイヤーでフィールドを使用します。

免責事項：私はMySQLのエキスパートではありません...しかし、これは問題についての私の理解です。

TEXTはmysql行の外に格納されていると思いますが、VARCHARは行の一部として格納されていると思います。mysqlの行には最大行長があります。VARCHARを使用して、行に格納できる他のデータの量を制限できます。

また、VARCHARが行の一部を形成しているため、そのフィールドを参照するクエリは、TEXTチャンクを使用するクエリよりもわずかに高速になると思います。

短い答え： 実用的、パフォーマンス、ストレージの違いはありません。

長い答え：

VARCHAR(3000)（またはその他の大きな制限）との間には本質的に（MySQLでは）違いはありませんTEXT。前者は3000 文字で切り捨てられます。後者は65535 バイトで切り捨てられます。（文字は複数バイトを取る可能性があるため、バイトと文字を区別しています。）

の制限が小さい場合、VARCHARに比べていくつかの利点がありTEXTます。

• 「小さい」とは、バージョン、コンテキストなどに応じて、191、255、512、767、または3072などを意味しますCHARACTER SET。
• INDEXes列にインデックスを付けることができる大きさには制限があります。（767または3072 バイト。これはバージョンと設定に依存します）
• 複合によって作成された中間テーブル SELECTs MEMORY（高速）またはMyISAM（低速）の2つの異なる方法で処理されます。「大きな」カラムが含まれる場合、遅い方の手法が自動的に選択されます。（バージョン8.0で大幅な変更が行われるため、この箇条書き項目は変更される可能性があります。）
• 前の項目に関連して、TEXT（とは対照的にVARCHAR）すべてのデータ型はMyISAMに直接ジャンプします。つまりTINYTEXT、生成された一時テーブルのほうが、同等のものよりも自動的に低下しVARCHARます。（しかし、これは議論を第三の方向に導きます！）
• VARBINARYのようなものVARCHARです。BLOBのようTEXTです。

他の回答への反論

元の質問では、1つのこと（どのデータ型を使用するか）が尋ねられました。受け入れられた回答は他の何かに答えました（オフレコストレージ）。その答えは古くなっています。

このスレッドが開始されて応答されたとき、InnoDBには2つの「行フォーマット」しかありませんでした。その後すぐに、さらに2つの形式（DYNAMICおよびCOMPRESSED）が導入されました。

の保存場所はTEXT、データ型の名前ではなく、サイズにVARCHAR()基づいています。以下のために更新され、大きなテキスト/ BLOBカラムのオン/オフレコードストレージの議論を参照してくださいこれを。

上記の答えは主な問題を十分に主張していません：次のような非常に単純なクエリでも

(SELECT t2.* FROM t1, t2 WHERE t2.id = t1.id ORDER BY t1.id) 

一時テーブルが必要な場合があり、VARCHARフィールドが含まれている場合はCHAR、一時テーブルのフィールドに変換されます。したがって、テーブルでVARCHAR(65000)フィールドが500 000行あるとすると、この列だけで6.5 * 5 * 10 ^ 9バイトが使用されます。このような一時テーブルはメモリ内で処理できず、ディスクに書き込まれます。影響は壊滅的なものになると予想できます。

ソース（メトリック付き）：https : //nicj.net/mysql-text-vs-varchar-performance/ （これは、「標準」（？）MyISAMストレージエンジンでのTEXTvs の処理を指しますVARCHAR。他のものとは異なる場合があります。例：InnoDB。）

VARCHARとTEXTの間には大きな違いがあります。VARCHARフィールドにはインデックスを付けることができますが、TEXTフィールドにはインデックスを付けることができません。VARCHARタイプのフィールドはインラインで格納され、TEXTはオフラインで格納されます。実際には、TEXTデータへのポインタのみがレコードに格納されます。

VARCHARを検索するよりも速く検索、更新、または削除するためにフィールドにインデックスを付ける必要がある場合は、どんなに大きくてもかまいません。これら2つのデータ型は性質が異なるため、VARCHAR（10000000）がTEXTフィールドと同じになることはありません。

• アーカイブにのみフィールドを使用する場合
• あなたはデータ速度の取得を気にしません
• 速度は気になりますが、検索クエリで演算子 '％LIKE％'を使用するため、インデックス作成はあまり役に立ちません
• データ長の制限を予測することはできません

TEXTに行くより。

Varcharはメールアドレスなどの小さなデータ用で、Textはニュース記事などのはるかに大きなデータ用、Blobは画像などのバイナリデータ用です。

Varcharのパフォーマンスは、メモリから完全に実行されるため、より強力ですが、データが次のように大きすぎる場合、これは当てはまりません。 varchar(4000)たとえば。

一方、テキストはメモリに固執せず、ディスクパフォ​​ーマンスの影響を受けますが、テキストデータを別のテーブルに分離し、左結合クエリを適用してテキストデータを取得することで回避できます。

Blobははるかに遅いので、10000レコードのコストがかかる10000画像などのデータが少ない場合にのみ使用してください。

速度とパフォーマンスを最大化するには、以下のヒントに従ってください。

1. 名前、タイトル、メールにvarcharを使用する

2. 大きなデータにはテキストを使用

3. 異なるテーブルの別々のテキスト

4. 電話番号などのIDで左結合クエリを使用する

5. Blobを使用する場合は、テキストと同じヒントを適用します

これにより、10 Mを超えるデータと最大10 GBのサイズが保証されたテーブルでクエリのコストがミリ秒になります。