我在 MySQL 中有一个消息表，用于在用户之间记录消息。除了典型的 id 和消息类型（所有整数类型），我需要将实际的消息文本保存为 VARCHAR 或 TEXT。我设置的前端限制为 3000 个字符，这意味着消息永远不会插入到数据库中，因为它比这更长。
是否有理由使用 VARCHAR（3000）或 TEXT？有一些关于编写 VARCHAR（3000）的东西，感觉有点违反直觉。我已经浏览了 Stack Overflow 上的其他类似帖子，但是能够获得特定于此类公共消息存储的视图。
TEXT和BLOB存储在表格之外，表格只有一个指向实际存储位置的指针。
VARCHAR与表内联存储。当大小合理时， VARCHAR会更快，其权衡取决于您的数据和硬件，您需要使用数据对真实世界场景进行基准测试。
更新 VARCHAR或TEXT是以内联方式存储还是以非记录方式存储取决于数据大小，列大小，row_format 和 MySQL 版本。它不依赖于 “文” 与 “VARCHAR”。
你能预测用户输入的时间吗？
VARCHAR（X）
案例：用户名，电子邮件，国家，主题，密码
文本
案例：消息，电子邮件，评论，格式化文本，HTML，代码，图像，链接
MEDIUMTEXT
案例：大型 json 体，短到中等长度的书籍，csv 字符串
LONGTEXT
案例：教科书，程序，多年的日志文件，哈利波特和火炬，科研记录
只是为了澄清最佳做法：
文本格式消息几乎总是存储为 TEXT（它们最终会被任意长）
字符串属性应存储为 VARCHAR（目标用户名，主题等）。
我知道你有一个前端限制，这是非常好的，直到它没有。 * grin * 诀窍是将 DB 视为与连接它的应用程序分开。仅仅因为一个应用程序限制了数据，并不意味着数据本质上是有限的。
什么是消息本身迫使他们永远不会超过 3000 个字符？如果它只是一个任意的应用程序约束（例如，对于文本框或其他东西），请在数据层使用TEXT字段。