VARCHAR和TEXT之间有一个巨大的差异。虽然VARCHAR字段可以被索引，但TEXT字段不能。VARCHAR类型字段内联存储，而TEXT则脱机存储，只有指向TEXT数据的指针实际存储在记录中。

如果你必须索引你的字段，以便更快的搜索，更新或删除，而不是使用VARCHAR，无论有多大。VARCHAR(10000000)永远不会与TEXT字段相同，因为这两种数据类型在本质上是不同的。

如果您只使用您的字段存档 你不关心数据 检索速度 你关心速度，但你会使用操作员 '%LIKE%'在您的搜索查询中，因此索引将没有多大帮助 你 无法预测数据长度的限制

而不是短信。

简单的回答是:没有实用性、性能或存储方面的差异。

长一点的回答:

(在MySQL中)VARCHAR(3000)(或任何其他较大的限制)和TEXT之间基本上没有区别。前者将在3000个字符处截断;后者将截断到65535字节。(我在字节和字符之间做了区分，因为一个字符可以包含多个字节。)

对于VARCHAR中较小的限制，有一些优于TEXT的优点。

"smaller" means 191, 255, 512, 767, or 3072, etc, depending on version, context, and CHARACTER SET. INDEXes are limited in how big a column can be indexed. (767 or 3072 bytes; this is version and settings dependent) Intermediate tables created by complex SELECTs are handled in two different ways -- MEMORY (faster) or MyISAM (slower). When 'large' columns are involved, the slower technique is automatically picked. (Significant changes coming in version 8.0; so this bullet item is subject to change.) Related to the previous item, all TEXT datatypes (as opposed to VARCHAR) jump straight to MyISAM. That is, TINYTEXT is automatically worse for generated temp tables than the equivalent VARCHAR. (But this takes the discussion in a third direction!) VARBINARY is like VARCHAR; BLOB is like TEXT. A table with several 'large' VARCHARs could hit a limit of 64KB for the whole table definition; switching to TEXT is a simple and practical fix. (Example: (42000) Row size too large, from an Oracle dump to a MySQL dump )

反驳其他答案

最初的问题只问了一件事(使用哪种数据类型);接受的答案回答了其他问题(非记录存储)。这个答案现在已经过时了。

当这个线程启动并应答时，InnoDB中只有两种“行格式”。不久之后，又引入了两种格式(DYNAMIC和COMPRESSED)。

TEXT和VARCHAR()的存储位置基于大小，而不是数据类型的名称。有关大型文本/blob列的记录内/记录外存储的最新讨论，请参见此。

你能预测用户输入的时长吗?

VARCHAR(X) Max Length: variable, up to 65,535 bytes (64KB) Case: user name, email, country, subject, password TEXT Max Length: 65,535 bytes (64KB) Case: messages, emails, comments, formatted text, html, code, images, links MEDIUMTEXT Max Length: 16,777,215 bytes (16MB) Case: large json bodies, short to medium length books, csv strings LONGTEXT Max Length: 4,294,967,29 bytes (4GB) Case: textbooks, programs, years of logs files, harry potter and the goblet of fire, scientific research logging

关于这个问题还有更多信息。

为了澄清最佳实践:

文本格式的消息几乎总是存储为Text(它们的长度是任意的) 字符串属性应该存储为VARCHAR(目标用户名、主题等)。

我知道你有一个前端限制，这很好，直到它没有。诀窍是把DB看作是与连接到它的应用程序分开的。仅仅因为一个应用程序限制了数据，并不意味着数据在本质上是有限的。

到底是什么原因迫使这些信息不能超过3000个字符呢?如果它只是一个任意的应用程序约束(例如，对于文本框或其他东西)，则在数据层使用text字段。

只是对这里这么多答案的更正，即使现在有点晚了。

MySQL可以根据它们的文档对文本字段进行完全索引。

提供的链接 https://dev.mysql.com/doc/refman/5.6/en/column-indexes.html

总的来说，写Varchar字段比写Text字段要长，但只有当你有大量的写请求时才会有影响

VARCHAR和TEXT之间有一个巨大的差异。虽然VARCHAR字段可以被索引，但TEXT字段不能。VARCHAR类型字段内联存储，而TEXT则脱机存储，只有指向TEXT数据的指针实际存储在记录中。

如果你必须索引你的字段，以便更快的搜索，更新或删除，而不是使用VARCHAR，无论有多大。VARCHAR(10000000)永远不会与TEXT字段相同，因为这两种数据类型在本质上是不同的。

如果您只使用您的字段存档 你不关心数据 检索速度 你关心速度，但你会使用操作员 '%LIKE%'在您的搜索查询中，因此索引将没有多大帮助 你 无法预测数据长度的限制

而不是短信。