MySQL varchar（2000）とテキスト？
私は平均してテキストの段落を保存する必要があります。これはデータベースに約800文字になります。まれに、最大2000〜2500文字になる場合があります。マニュアルを読み、これらの質問の多くがすでにあることを知っていますが、stackoverflowに関する10以上の質問を読んだので、単にテキストを使用するのか、varchar（ 2000）。半分はvarcharを使用すると言っているようですが、残りの半分はテキストと言っています。 255文字を超える場合は常にテキストを使用すると言う人もいます（そうです、これは5.0.3以降で、最大65kのvarcharが許可されていました）。しかし、文字が255を超えるたびにテキストを使用するのではないかと思いました。それが常に最良のオプションであるのに、なぜmysqlがサイズを大きくする必要があるのでしょうか。
どちらも私が読んだストレージのサイズは可変なので、状況に違いはありませんか？私は個人的にvarchar（2000）に傾倒していたので、varcharはデータをインラインで格納し、テキストは格納しないことを読みました。これは、この列を常に選択する場合、データをvarcharとして保存する方がよいことを意味します。逆に、この列をめったに選択しない場合は、テキストを使用する方がよいということですか？それが本当なら、私はテーブルでクエリを実行することが多いので、この列を選択しないので、テキスト列を選択すると思います。重要な場合は、このテーブルも頻繁に結合されます（ただし、列は選択されません）。これにより、テキストを使用する利点もさらに高まりますか？
この場合、テキストを使用する必要があるという私の仮定は正しいですか？
テーブルにTEXT列またはBLOB列がある場合、そのテーブルをメモリに保存することはできません。これは、すべてのクエリ（キャッシュにヒットしない）がファイルシステムにアクセスする必要があることを意味します。これは、メモリよりも桁違いに低速です。
したがって、このTEXT列は、実際に必要な場合にのみアクセスされる別のテーブルに格納する必要があります。このようにして、元のテーブルをメモリに保存でき、はるかに高速になります。
データを1つの「メモリテーブル」と1つの「ファイルテーブル」に分割することと考えてください。これを行う理由は、必要な場合（つまり、テキストが必要な場合のみ）を除いて、ファイルシステムへのアクセスを回避するためです。
テキストを複数のテーブルに保存しても、何も得られません。それでもファイルシステムにアクセスする必要があります。
申し訳ありませんが、たとえばフォーラムスクリプトは、投稿テーブルに20列の投稿データを保存している可能性があり、実際の投稿も同じテーブルのテキストフィールドとして保存します。そのため、投稿列を分離する必要がありますか？
はい。
Postというテーブルがあるのは奇妙に思えますが、実際の投稿はそこに保存されていません。おそらく、「actual_post」という別のテーブルに保存されているのではないでしょうか。
（posts、post_text）または（post_details、posts）またはそのようなものを試すことができます。
Tag_id、tag、descriptionの3つのフィールドしかないタグテーブルがあります。 >説明の列も分離する必要がありますか？したがって、3つの列を格納するためだけにtagsテーブルと> tags_descriptionテーブルが必要ですか？
説明がTEXT列であり、説明を必要としないこのテーブルに対してクエリを実行する場合は、確かに望ましいでしょう。
うまくまとめられたと思います。考えられるもう1つのことは、「テキスト」を別のテーブルに移動して、マスターレコードに結合することです。そうすれば、実際にマスターテーブルを使用するたびに、「テキスト」がどこにあるかという余分なデータがマスターレコードのスペースを占有することさえありません。必要なときに、そのテーブルに参加できます。このようにして、「where text like ...」のようなことをしたい場合に備えて、varcharとして保存できます。