MySQL 中 VARCHAR 和 TEXT 的区别

当某个值有实用的声明上限，且常用于常规列查询时，可选择 VARCHAR。当内容较长或实际大小较难预估时，可选择 TEXT。合适的选择取决于预期数据、应用程序应执行的限制，以及该列的查询方式；没有一种类型在所有情况下都更快或更好。

VARCHAR 和 TEXT 存储什么

在 MySQL 中，VARCHAR 和 TEXT 都用于存储字符数据，但体现了不同的架构预期。VARCHAR(n) 会为列声明长度，适合有明确最大长度的值，例如显示名称或简短标签。TEXT 列则用于较长文本，例如用户评论或文章正文；当较短的声明上限无法恰当地描述这类数据时，可以考虑使用它。

类型名称不会替应用程序决定验证规则。应在插入之前确定哪些值可以接受，并让列类型与这项规则相符。例如，电话号码可能较短，但不应因此自动将其存为数字：如果按文本处理，可以使用设定了合适应用程序上限的 VARCHAR 来表示。

长度限制与存储成本

VARCHAR(n) 中的数字表示声明的字符数上限，而实际存储的值可以更短。实际存储方式和允许的大小取决于架构以及 MySQL 的适用限制；字符集和行定义也会产生影响。这些因素会随所用的 MySQL 版本、字符集和表定义而异，因此应查阅对应部署环境的文档，而不要依赖通用的字节成本或最大长度计算。

不要只凭「某一种类型总是更省空间」这类说法来选择类型。应综合考虑预期值的长度、声明上限和整体表设计。TEXT 可用于较长内容，而 VARCHAR 则能在架构中直接表达值的长度有界。

索引与查询注意事项

索引需求应纳入设计考量。先考虑应用程序会对哪些列进行筛选、排序或联结，再针对部署所用的 MySQL 版本和架构，确认合适的索引定义。TEXT 并非绝对无法建立索引，但可用选项和限制可能取决于这些具体条件。不要假设任一类型都能保证特定的查询速度；如果性能很重要，应在自己的环境中测量有代表性的查询。

根据数据选择类型

先考虑值的含义和预期范围。如果能设定实用的长度上限，有界标签、电子邮件地址或显示名称通常适合使用 VARCHAR。较长的用户评论或文章内容则可能适合 TEXT。这些只是示例，并非固定规则：不同应用程序可能有不同的限制或查询模式。

接着考虑该列的用途。如果经常按该列搜索或排序，应在架构设计和索引审查时纳入这种访问模式。如果产品对值有明确限制，应在插入前由应用程序验证，并在列设计中体现该限制。这样可以明确预期行为，而不必依赖服务器对超长输入会如何处理这类未说明的行为。

架构示例与长度处理

一个简单的个人资料表可以对有界字段使用 VARCHAR，并对可选的个人简介使用 TEXT。内联架构 CREATE TABLE profile (display_name VARCHAR(80), phone VARCHAR(32), biography TEXT); 展示了这两种类型的用途；请根据自身需求选择长度上限，并确认部署环境适用的索引选择。

如果字段长度由应用程序管理，应在把值传给数据库之前进行验证。这个 Python 示例会返回每个值是否符合已配置的字符数规则；应用程序可以根据 False 结果拒绝该值。示例本身只报告检查结果，并不会拒绝输入，也不演示 MySQL 的插入行为，更不能取代服务器端约束。第一个值有 12 个字符，未超过 80 个字符的上限；第二个值有 81 个字符，超过了上限。

运行以下示例。代码和输出保持原样，其中的 True 和 False 标签为英文：

本节中的代码以及显示的标签或输出仍为英文。

values = ["Ada Lovelace", "x" * 81]
max_characters = 80
for value in values:
    print(len(value) <= max_characters)

True
False