在 MySQL 中使用 text 而不是 varchar 类型的真正性能影响是什么？答案

【问题标题】：What are real performance implications of using text instead of varchar types in MySQL?在 MySQL 中使用 text 而不是 varchar 类型的真正性能影响是什么？
【发布时间】：2011-01-02 07:29:32
【问题描述】：

在 MySQL 中何时使用 text 类型而不是大的 varchar 是否有任何比较、个人经验或指南？

虽然我的数据库中的大多数条目都少于 1000 个字符，但有些可能会占用 4000 个字符或更多。 varchar 的限制长度是多少，这使得 text 成为更好的变体？

我不需要索引这些字段。

【问题讨论】：

你不会在 WHERE 子句或 SELECT 子字符串中使用列，对吧？
@Thilo：对，我不会在 WHERE 中使用它。
文本很好，只要您不将该列作为输出列包含在结果集中。 IE。仅在返回单行的查询中返回文本列。注意：这在任何情况下都应该是很自然的事情，因为这样的“大”列只有在向用户呈现特定行时才真正有用。然而，一些开发者犯了过度使用SELECT * FROM ...的错误。

标签： sql mysql database varchar

【解决方案1】：

当然，最好的了解方法是使用您的真实数据集自己运行一些测试，或者至少使用模拟的等效数据集。只需编写一些脚本来填充数据并运行您的选择。使用不同大小的 varchar 进行测试，然后是文本，并测量时间和整体系统利用率（cpu/负载、内存、磁盘 i/o）。

如果你有足够的负载，这很重要，那么无论如何你都应该进行自动化测试。

【讨论】：

我认为这对许多数据库架构师来说很有趣，他们不一定会拘泥于一种具体的布局和架构。这种“自己找”的答案对我和其他任何人都没有用。 :)

【解决方案2】：

我没有亲身经历，但这个人有：

VARCHAR vs. TEXT - some performance numbers

快速回答：varchar 快了很多。

编辑 - 不，不是。他对它们进行了不同的索引——他在 varchar 上有一个完整的索引（255 个字符），但在文本上有一个 255 个字符的前缀索引。当他删除它时，它们的表现或多或少相同。

在线程的后面是这个有趣的花絮：

当需要一个 tmp 表时 SELECT，第一选择是使用 MEMORY，这将是 RAM-only，因此可能明显更快。（第二选择是 MyISAM。）但是，TEXT 和 MEMORY中不允许BLOB，所以它不能使用它。（还有其他原因为什么它可能会跳过 MEMORY。）

编辑 2 - 一些更相关的信息，这次比较不同索引处理各种类型的方式。

MyISAM 将 TEXT 和 BLOB 置于“内联”。如果您正在搜索一个表（范围扫描 / 表扫描），你正在'跨过那些奶牛稻田——磁盘成本很高输入/输出。也就是说，存在内联 blob 会损害性能案例。

InnoDB 只放置 767 个字节的 TEXT 或 BLOB 内联，其余的进入其他一些块。这是一个妥协有时有帮助，有时会伤害性能。

其他东西（玛丽亚？猎鹰？InnoDB 插件？）完全放置 TEXT 和 BLOB 别处。这将使性能上的明显差异与 VARCHAR 相比。有时 TEXT 会更快（例如，范围扫描不需要blob）；有时 VARCHAR 会更快（例如，如果您需要查看它和/或归还）。

【讨论】：

好吧，但在那篇文章中，TEXT/VARCHAR 列用作主键。 OP 说他不会为该列编制索引。
Thilo - 你是对的，我只是想解决“文本与 varchar 的性能影响”这一更普遍的问题。其他阅读者可能会发现它很有用。
是的，但我认为测量受到索引的影响。我不会将文本列设为主键。
临时表到底是什么意思？是经常使用还是很少使用？
谢谢，我在之前的调查中也发现了这些 cmets。虽然很有趣，但很难从这些信息中猜出对相对较小（公斤而不是兆）条目的真正影响是什么。