質問
小さな記事システムの Web サイトの場合、コンテンツの保存に使用するフィールドとして varchar(8000) を選択しました。最大 4000 文字の漢字を保持でき、ほとんどのユーザーにとってはこれで十分です。しかし、1 つの問題は、ユーザーがコード (HTML、JS、CSS など) を入力できるようにすることです。コードが保存されると、実際にはさらに多くの入力が必要になります。
それでは、varchar または text を使用する必要がありますか? それとも他のものを使用する必要がありますか?
結論は
使用文章
材料
文章
TEXTには4種類あります。
- TINYTEXT 256バイト
- テキスト 64kb
- ミディアムテキスト 16Mb
- 長文 4GB
注釈を使用する
@Lob
@Basic(fetch=FetchType.LAZY)
@Column(columnDefinition="TEXT",nullable=true)
public String getContent() {
return Content;
}
BLOB
タイニーブロブ
- ブロブ、
- ミディアムブロブ
- ルングブロブ
Blob はバイナリ データを保存するため、この機能を使用して画像をデータベースに保存できます。 text はテキストのみを保存できます。
注釈を使用する
@Lob
@Basic(fetch=FetchType.LAZY)
@Column(columnDefinition="BLOB",nullable=true)
public String getContent() {
return Content;
}
テキストとブログ
TEXT
:最大長 65535 (2^16-1) 文字の可変長の非 Unicode データを格納します。
MEDIUMTEXT
:最大長 16777215 (2^24-1) 文字の可変長の非 Unicode データを格納します。
LONGTEXT
:最大長 2147483647 (2^32-1) 文字の可変長の非 Unicode データを格納します。
TINYTEXT
:最大長 255 (2^8-1) 文字の可変長の非 Unicode データを格納します。
TEXT に似たデータ型は BLOG ですが、違いは次のとおりです。
-
BLOB にはバイナリ データが格納され、TEXT には文字データが格納されます。
-
BLOB を使用する利点は、テキストと画像の両方をバイナリ形式でデータベースに保存できることです。しかし、残念なことに、現在ではほとんどの画像がタグ付きでフロントエンドに導入されており、画像ベッドや CDN の出現により、直接的にはテキスト データのみが独自のデータベースに保存されるようになり、TEXT がより一般的に使用されるようになりました。
-
BLOB 列には文字セットがなく、並べ替えと比較は列値のバイトの数値に基づいて行われます。 TEXT列には文字セットがあり、その文字セットの照合規則に従って値がソートおよび比較されます。したがって、漢字を含むファイルを保存する場合は、TEXT を使用することをお勧めします。
TEXTとBLOGの共通点:
-
文字長制限が異なる 4 つのデータ型があります。
-
BLOB 列および TEXT 列から値を保存または取得するときに、末尾のスペースは削除されません。
-
BLOB 列および TEXT 列のインデックスの場合、インデックスの接頭辞の長さを指定する必要があります。
-
BLOB 列と TEXT 列にはデフォルト値を設定できません。
-
ソート時には、列の最初の max_sort_length バイトのみが使用されます。 max_sort_length のデフォルト値は 1024 です。
-
長い値を含む BLOB 列または TEXT 列で GROUP BY または ORDER BY を使用するもう 1 つの方法は、max_sort_length を超えるバイトを理解する必要がある場合に、列の値を固定長オブジェクトに変換することです。標準的なアプローチは、SUBSTRING 関数を使用することです。
-
BLOB または TEXT オブジェクトの最大サイズはその型によって決まりますが、クライアントとサーバー間で受け渡しできる実際の最大サイズは、使用可能なメモリの量と通信バッファのサイズによって決まります。 max_allowed_packet 変数の値を変更することでメッセージ バッファのサイズを変更できますが、サーバー プログラムとクライアント プログラムの両方を変更する必要があります。
使用方法: 画像とテキストが混在したバイナリ データを保存したり、中国語のテキストを保存したりしない場合は、TEXT を使用することをお勧めします。
CHAR と VARCHAR
CHAR
固定長データの格納に使用される CHAR フィールドのインデックスは非常に効率的ですが、文字長が不確実なデータには適していません。たとえば、char(10) を定義すると、保存するデータが 10 バイトに達するかどうかに関係なく、10 バイトの領域が占有されます。
VARCHAR
上記の問題を解決するために、SQL は可変長データ型を格納するように設計されていますが、その結果、格納効率が低下します。フィールドの取り得る値が固定長でない場合、10 文字を超えることができないことだけがわかり、VARCHAR(10) として定義するのが最もコスト効率が高くなります。
VARCHAR 型の実際の長さは、その値の実際の長さ + 1 です。なぜ「+1」なのでしょうか?このバイトは、実際に使用される長さを保存するために使用されます。
用法
: スペースの観点からは varchar が適切であり、効率の観点からは char が適切であり、実際の状況に基づいてトレードオフのポイントを見つけることが重要です。
NCHAR、NVARCHAR、NTEXT
前のタイプの前に N を追加します。 Unicodeデータ型の文字が格納されていることを示します。
-
英語では通常、文字の格納に必要なバイト数は 1 バイトだけであるため、アルファベットといくつかの記号文字で構成されるエンコード テーブルのみが必要です。ただし、中国語の各漢字は文字の組み合わせではなく、より多くの記憶領域を必要とし、通常は 2 バイトを占有します。
-
さまざまな言語の文字と互換性を持たせるためには、Unicode 文字セットを使用する必要があり、そのすべての文字は 2 バイトで表現され、英語の文字も 2 バイトで表現されます。
-
nchar および nvarchar データ型を使用すると、入力文字が英語か中国語かを気にする必要がなく便利であることがわかりますが、英語を格納すると量が若干失われます。
使用法: 中国語の文字が含まれる場合は、nchar/nvarchar を使用し、純粋な英語と数字が含まれる場合は、char/varchar を使用します。
mysqlのテキスト、ロングテキスト、ミディアムテキストの違い
1。概要
MySQL では、テキスト、ミディアムテキスト、およびロングテキストはすべて、大量のテキスト データを保存するために使用されるデータ型です。
- TEXT: TEXT データ型は、最大長 65,535 (2^16-1) 文字のテキスト データを格納するために使用できます。保存されたデータがこの長さを超えると、MySQL はエラーをスローします。
- MEDIUMTEXT: MEDIUMTEXT データ型は、最大長 16,777,215 (2^24-1) 文字のテキスト データを格納するために使用できます。 MEDIUMTEXT型はTEXT型に比べてより多くのデータを格納できます。
- LONGTEXT: LONGTEXT データ型は、最大長 4,294,967,295 (2^32-1) 文字のテキスト データを格納するために使用できます。すべてのテキスト タイプの中で最も多くのデータを保存します。
これらのデータの種類のうち、保存されるデータが大きいほど、占有される記憶領域も大きくなります。したがって、データベースを設計するときは、ストレージ領域の無駄を避けるために、実際の状況に基づいて適切なデータ型を選択する必要があります。
さらに、これらのデータ型は Unicode 文字セット (UTF-8) でエンコードされることに注意してください。データを非 Unicode 文字セットで保存する必要がある場合は、CHAR や VARCHAR などの別のデータ型を選択できます。
ストレージ容量の違いに加えて、これらのテキスト タイプには他にもいくつかの違いがあります。
- 記憶域: 同じデータを保存する場合、LONGTEXT 型は MEDIUMTEXT および TEXT 型よりも多くの記憶域を占有します。
- パフォーマンス: LONGTEXT 型はより多くの記憶領域を占有するため、LONGTEXT 型データはクエリや並べ替えなどの操作の実行に時間がかかります。
- インデックス: テキスト型データは比較的大きいため、インデックスを使用する場合は特別な注意を払う必要があります。テキスト型データのインデックスを作成する場合は、パフォーマンスの問題を回避するために、プレフィックス インデックスやフルテキスト インデックスなどのテクノロジを使用する必要があります。
データ型: これらのテキスト型は大量のテキスト データを保存できますが、MySQL のデータ型は異なります。 TEXT 型は、TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT の中で最小のデータ ストレージ タイプです。したがって、より小さいテキスト データを保存する必要がある場合は、TINYTEXT タイプを使用できます。
つまり、データベースを設計するときは、実際のニーズに基づいて適切なデータ型を選択する必要があります。小さなテキスト データを保存する必要がある場合は、TINYTEXT タイプを使用でき、大量のテキスト データを保存する必要がある場合は、MEDIUMTEXT または LONGTEXT タイプを使用できます。インデックスを使用する場合は、パフォーマンスの問題を避けるために注意する必要があります。
2. 異なるバイト制限
1. テキスト フィールド タイプ: テキスト フィールド タイプのバイト制限は 65535 バイトです。
2. ロングテキスト フィールド タイプ: ロングテキスト フィールド タイプのバイト制限は 2147483647 バイトです。
3. ミディアムテキスト フィールド タイプ: ミディアムテキスト フィールド タイプのバイト制限は 16777215 バイトです。
3. I/O が異なります
1. テキスト フィールド タイプ: テキスト フィールド タイプは、ロングテキストおよびミディアムテキスト フィールド タイプよりも冗長 I/O が発生する可能性が低くなります。
2. ロングテキスト フィールド タイプ: ロングテキスト フィールド タイプは、テキスト フィールドやミディアムテキスト フィールド タイプよりも冗長 I/O を引き起こす可能性が高くなります。
3. ミディアムテキスト フィールド タイプ: ミディアムテキスト フィールド タイプは、テキスト フィールド タイプよりも冗長 I/O が発生する可能性が高く、ロングテキスト フィールド タイプよりも冗長 I/O が発生する可能性が低くなります。
4. 行の移行は異なります
1. テキスト フィールド タイプ: テキスト フィールド タイプは、ロングテキストおよびミディアムテキスト フィールド タイプよりも行の移行を実行するのが簡単です。
2. ロングテキスト フィールド タイプ: ロングテキスト フィールド タイプは、テキスト フィールドやミディアムテキスト フィールド タイプに比べて行の移行を実行するのが簡単ではありません。
3. ミディアムテキスト フィールド タイプ: ミディアムテキスト フィールド タイプは、テキスト フィールド タイプよりも行の移行を実行するのが簡単ではありませんが、ロングテキスト フィールド タイプよりも行の移行を実行するのが簡単です。
ありがたい
上記の内容のリファレンス
https://blog.csdn.net/strivenoend/article/details/80462044
https://blog.csdn.net/u011262253/article/details/105587518
https://blog.csdn.net/qyj19920704/article/details/123924672