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

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

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

Varchar适用于电子邮件地址这样的小数据，而Text适用于新闻文章这样的大数据，Blob适用于图像这样的二进制数据。

Varchar的性能更强大，因为它完全从内存中运行，但如果数据太大，例如Varchar(4000)，情况就不一样了。

另一方面，文本不固定在内存中，并且受到磁盘性能的影响，但是可以通过将文本数据分离到单独的表中并应用左连接查询来检索文本数据来避免这种情况。

Blob要慢得多，所以只有当你没有很多数据时才使用它，比如10000张图片，这将花费10000条记录。

遵循以下技巧获得最大的速度和性能:

使用varchar记录姓名，头衔，电子邮件 大数据使用文本 在不同的表格中分离文本 对一个ID(比如电话号码)使用左连接查询 如果你要使用Blob，应用与文本相同的技巧

这将使数据> 10m和最大10GB的表上的查询花费毫秒。

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

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

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

而不是短信。

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

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

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

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

为了澄清最佳实践:

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

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

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

免责声明:我不是MySQL专家…但这是我对问题的理解。

我认为文本存储在mysql行之外，而我认为VARCHAR存储为行的一部分。mysql的行有一个最大的行长。所以你可以使用VARCHAR限制你可以在一行中存储多少其他数据。

同样由于VARCHAR构成了行的一部分，我怀疑查看该字段的查询将比使用TEXT块的查询略快。