【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
我在MySQL中有一个消息表，该表记录了用户之间的消息。 除了典型的ID和消息类型（所有整数类型）之外，我还需要将实际消息文本另存为VARCHAR或TEXT。 我将前端限制设置为3000个字符，这意味着消息插入数据库的时间绝不会超过此时间。
是否有理由使用VARCHAR（3000）或TEXT？ 只是编写VARCHAR（3000）有点不合常理。 我曾经在Stack Overflow上浏览过其他类似的文章，但是最好获得特定于这种常见消息存储类型的视图。
#1楼
您能预测用户输入多长时间吗？
VARCHAR（X）
案例：用户名，电子邮件，国家/地区，主题，密码
文本
案例：消息，电子邮件，评论，格式化文本，html，代码，图像，链接
中文字
案例：大型json正文，中短长度的书籍，csv字符串
长文本
案例：教科书，程序，日志文件的年限，哈利·波特与火焰杯，科学研究记录
#2楼
TEXT和BLOB存储在表外，该表仅具有指向实际存储位置的指针。VARCHAR与表内联存储。 在大小合理的情况下，VARCHAR更快，其折衷会更快，具体取决于您的数据和硬件，您希望使用数据对真实场景进行基准测试。
更新 VARCHAR还是TEXT是内联存储还是非记录存储取决于数据大小，列大小，row_format和MySQL版本。 它不依赖于“文”与“VARCHAR”。
#3楼
免责声明：我不是MySQL专家...但这是我对问题的理解。
我认为TEXT存储在mysql行之外，而我认为VARCHAR存储为该行的一部分。 mysql行有一个最大行长度。因此，您可以使用VARCHAR限制一行中可以存储多少其他数据。
同样由于VARCHAR构成了行的一部分，我怀疑查看该字段的查询会比使用TEXT块的查询稍快。
#4楼
只是为了阐明最佳做法：
文本格式的消息几乎应始终存储为TEXT（它们最终会任意长）
字符串属性应存储为VARCHAR（目标用户名，主题等）。
我知道您有一个前端限制，这很好，直到没有限制为止。 *咧嘴*诀窍是将数据库与连接到数据库的应用程序分开考虑。 仅仅因为一个应用程序对数据进行了限制，并不意味着数据本身就受到限制。
消息本身是什么使它们不能超过3000个字符？ 如果这只是一个任意的应用程序约束（例如，对于文本框之类的东西），请在数据层使用TEXT字段。
#5楼
简短的回答：没有实用性，性能或存储差异。
长答案：
VARCHAR(3000) （或任何其他大限制）和TEXT之间基本上没有区别（在MySQL中）。 前者将截断3000个字符 ; 后者将截断为65535 字节 。 （我区分字节和字符，因为一个字符可以占用多个字节。）
对于VARCHAR较小限制，相对于TEXT有一些优点。
- “较小”表示191、255、512、767或3072等，具体取决于版本，上下文和
CHARACTER SET。 -
INDEXes在可索引的列INDEXes方面受到限制。 （767或3072 字节 ；这取决于版本和设置） - 由复杂的
SELECTs创建的中间表以两种不同的方式处理-MEMORY（更快）或MyISAM（更快）。 如果涉及“大”列，则会自动选择较慢的技术。 （8.0版中将进行重大更改；因此，此项目符号可能会有所更改。） - 与上一项有关，所有
TEXT数据类型（与VARCHAR相对）都直接跳到MyISAM。 也就是说，对于生成的临时表，TINYTEXT自动比等效的VARCHAR。 （但这将讨论引向了第三方向！） -
VARBINARY就像VARCHAR一样；BLOB就像TEXT一样。
反驳其他答案
最初的问题是一件事（使用哪种数据类型）。 接受的答案回答了其他问题（记录外存储）。 该答案现在已过期。
当启动并回答该线程时，InnoDB中只有两种“行格式”。 此后不久，又引入了两种格式（ DYNAMIC和COMPRESSES ）。
TEXT和VARCHAR()的存储位置基于大小 ，而不是数据类型的名称 。 有关大型text / blob列的开/关记录存储的最新讨论，请参见this 。
来源：oschina
链接：https://my.oschina.net/stackoom/blog/3144471