哪种 DATATYPE 更适合使用 TEXT 或 VARCHAR？

Posted 2023-02-24

【中文标题】哪种 DATATYPE 更适合使用 TEXT 或 VARCHAR？

【英文标题】：Which DATATYPE is better to use TEXT or VARCHAR?

【发布时间】：2010-11-15 06:42:09

【问题描述】：

这个问题基于 performance 和 size

两件事

基于性能哪些会影响哪些会提高？

【问题讨论】：

注意：许多答案和评论要么已过时，要么从未完全正确。

【参考方案1】：

VARCHAR 您可以设置每条记录将接受多少个字符的限制，文本（实际上）是无限的......不完全确定性能，但我会假设更具体的数据类型（varchar）会更快。

【讨论】：

65535 字节不是“虚拟”限制。

【参考方案2】：

VARCHAR 应该有更好的性能，因为它的大小是有限的。事实上，在我使用 mysql 的所有经验中，VARCHAR 的搜索操作总是比 TEXT 快。无论如何，这是基于我的经验。您应该查看文档以了解更多信息。

【参考方案3】：

这取决于您使用它的目的。我不想给出如此笼统的答案，但这是真的。通常，尝试尽可能具体地获取数据类型。如果您的字符串永远不会超过某个字符的上限，那么请使用VARCHAR，因为它会更有效率。如果您需要更多空间，请使用TEXT。如果您不确定您的文本将占用多少空间，您可能应该使用TEXT；性能差异不是很大，最好是面向未来，而不是在您的需求发生变化时冒着改变它的风险。只是我的两分钱。

---

在 cmets 中，Pitarou 指出，如果 MySQL 为您的查询创建一个临时表（请参阅this），TEXT 列将不会存储在内存中，而必须从磁盘中读取，即慢得多。 （Source，页面底部。）不过，这对于大多数查询来说应该无关紧要。

如果有人想知道 PostgreSQL 的比较，我发现 this benchmark 表明 CHAR、VARCHAR 和 TEXT 的性能都一样好。因此，如果您使用的是 Postgres，那么您使用什么类型并不重要。

【讨论】：

+1 因为它总是如此。顺便说一句，我之前已经将列从 varchar 更改为 text，并且似乎都可以很好地转换。看来mysql会在数据类型发生变化时尝试智能转换数据。

MySQL 文档指出 TEXT 可能会更慢，因为 MEMORY 存储引擎不支持这种数据类型，所以你应该只在真正需要时才使用 TEXT。 dev.mysql.com/doc/refman/5.5/en/blob.html

@Pitarou：仅当您使用的查询会生成临时表时，这对于简单的查询无关紧要。不过，很好的发现，知道这很有用。

我认为@noushy 对于 MySQL >= V 5.0.3 有 better answer，因为 VARCHAR 允许从该版本开始最多 64k 的长度。因此，与 TEXT（顺便说一下，它的上限为 64k）相比，它没有任何缺点，同时仍然具有更好的性能。

我可能还会再问这个问题，因为这个问题太老了；但发生在你的味精上，巴斯蒂安。在我的例子中，一个 msSQL2008 触发器给出了这个错误：“不能在 'inserted' 和 'deleted' 表中使用 text、ntext 或 image 列。”所以我们选择将我们的文本字段转换为 varchar(max) [on dev db]。我们担心/希望移植到 prod 数据库时不会丢失数据或完整性问题。寻找线索。

【参考方案4】：

这真的取决于你的数据类型。

如果您的字段是固定长度的（例如 32 个字符的哈希值），则使用 CHAR。这具有更好的性能，因为每个条目每行占用相同的空间。

VARCHAR 的标准限制是 255 个字符，但我认为现在已经增加了。 TEXT 非常长，通常只用于大型内容，如整篇博客文章，如果您不想要限制，则使用 cmets。

关于大小，VARCHAR 和 TEXT 之间没有（或很少）差异，因为它们只是存储他们需要的内容。 CHAR 字段将始终占用其分配的长度。

在性能方面，VARCHAR 通常更快。 VARCHAR 也可以被索引，从而加快搜索速度。

【参考方案5】：

MySQL 在创建临时表时会在内部将 TEXT 转换为 varchar。因此，如果可能，最好使用 VARCHAR。有一些与 TEXT 列相关的小错误，例如...

http://bugs.mysql.com/bug.php?id=36676

【讨论】：

并不总是更好的解决方案！ nicj.net/mysql-text-vs-varchar-performance

【参考方案6】：

从 V 5.0.3 开始，VARCHAR 的限制从 0-256 增加到 0-65,535（取决于最大行大小（65,535 字节，在所有列之间共享）和使用的字符集。）

参考。 http://dev.mysql.com/doc/refman/5.0/en/char.html

如果您使用的是固定长度为 64k 的 TEXT，即使您需要的限制更少

所以最好使用具有更高限制的VARCHAR而不是TEXT。 如果要求超过 64K，请相应地使用 MEDIUMTEXT 或 LONGTEXT。

【讨论】：

这是真的吗，固定的 64k 长度？数据不是像单独的文本文件一样存储在磁盘上吗？

@SimonBaars - 不固定 64k。不是单独的文件；单独的块，并非总是如此。

【参考方案7】：

根据我的意见，当您知道字符长度时，VARCHAR 是最佳选择。它还将减少垃圾内存分配和空间问题。 TEXT 将消耗 255，而 VARCHAR 将消耗你给它的值。

根据性能，VARCHAR 也比 TEXT 更快。

【参考方案8】：

text 和 varchar 有细微的差别。我有一张如图所示的表格：

CREATE TABLE `test`.`tbl`(
  `kee` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  `txt` TEXT(100),
  `vrchr` VARCHAR(100),
  PRIMARY KEY (`kee`)
);

我插入一行：

 INSERT INTO `tbl`
            (`txt`,
             `vrchr`)
VALUES ('1        
         2
         3',
        '1
         2
         3');

txt 列的值为：1 2 3 并且列 vrchr 具有值：1

【讨论】：

您确定您使用的是 DBMS？

不知道你为什么在这件事上受到如此严重的打击。对于存储包含用于打印的换行符的字符串的人来说，帮助调试丢失的字符非常重要。

【参考方案9】：

针对 TEXT 表的查询总是比针对 VARCHAR 表的查询慢 3 倍（平均值：VARCHAR 表为 0.10 秒，TEXT 表为 0.29 秒）。差异是 100% 可重复的。

来自http://forums.mysql.com/read.php?24,105964,105964的基准

【讨论】：

基准测试是假的——TEXT 版本在PRIMARY KEY 中使用前缀索引。但VARCHAR 版本没有。