MySQL TEXT 和 VARCHAR 有什么区别？存储文章内容时应该如何选择

在MySQL数据库中，VARCHAR和TEXT都可以保存字符串，但两者的设计目标并不相同。VARCHAR更适合长度相对可控、经常参与条件查询、排序或索引的字符串字段；TEXT则主要用于保存长度较大的正文、说明、文档和其他长文本。对于新闻网站、博客系统和内容管理系统来说，文章正文究竟使用VARCHAR还是TEXT，不能只看“能存多少字”，还要结合字符集、索引、行存储方式以及实际查询模式判断。

VARCHAR的最大长度并不是简单的65535个字符，而是受到MySQL单行最大长度、字符集以及其他列共同影响的字节数限制。65535字节是VARCHAR在特定条件下受到的行记录限制，而不是一个独立的“VARCHAR字段永远最多只能保存65535字节”的简单规则。使用utf8mb4时，一个字符最多可能占4个字节，因此VARCHAR(65535)实际上无法在普通表结构中直接理解为可以保存65535个字符。其他列占用的空间也会影响实际能够声明的最大长度。

VARCHAR(N)中的N表示字符长度，而不是字节长度。例如VARCHAR(1000)表示最多1000个字符，但实际占用的字节数取决于字符集。utf8mb4中的字符可能使用1至4个字节，因此不能用“1000字符等于4000字节”这种方式理解所有字符串。

TEXT则属于MySQL专门用于较长字符串的类型。TEXT、MEDIUMTEXT和LONGTEXT分别提供不同的容量范围，因此如果文章可能达到几十KB、几百KB甚至更大，可以根据实际数据规模选择不同级别，而不是简单地认为“所有正文都必须使用TEXT”。

TEXT本身也不是一种单一的存储机制。MySQL的InnoDB会根据行格式、字段长度等条件处理较长的可变长度字段，部分数据可能以页外形式存储。因此，不能简单地写成“TEXT单独存储并额外增加12字节”，也不能把VARCHAR描述成“全部在内存中、TEXT全部在磁盘上”。真正的数据访问行为取决于存储引擎、行格式、记录大小以及查询方式。

VARCHAR和TEXT还有一个非常重要的区别，就是索引设计。TEXT并不是“无法创建索引”，而是通常不能像普通VARCHAR那样直接把整个超长字段作为一个普通索引键来使用。在InnoDB等存储引擎中，可以根据具体需求建立前缀索引，例如：

CREATE INDEX idx_content_prefix ON articles(content(255));

这里的255表示索引前缀长度，并不意味着数据库只能查询正文前255个字符。索引只是利用前缀帮助定位候选记录，最终查询仍然可以读取完整字段。

如果业务需要全文检索，则应该考虑MySQL的FULLTEXT索引以及专业搜索引擎。FULLTEXT与普通B-Tree索引解决的问题不同，不能简单理解成“TEXT字段适合全文搜索”。是否使用FULLTEXT，取决于搜索需求、语言、分词方式、数据规模以及查询复杂度。

对于文章标题，VARCHAR通常更加合适。例如标题一般需要参与列表查询、排序、唯一性约束或者普通索引，可以设计成VARCHAR字段。文章正文则通常使用TEXT、MEDIUMTEXT等类型，因为正文长度变化较大，而且通常不会把整个正文建立成普通B-Tree索引。

一个常见的文章表可以这样设计：

CREATE TABLE articles (
id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(255) NOT NULL,
summary VARCHAR(1000),
content MEDIUMTEXT NOT NULL,
created_at DATETIME NOT NULL,
INDEX idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里的content使用MEDIUMTEXT，而不是盲目使用最大的LONGTEXT。对于一般新闻、博客和CMS文章，MEDIUMTEXT已经能够提供远超普通文章实际需求的容量。如果确定正文永远不会接近这个范围，TEXT也完全可以满足要求。

反过来，如果正文经过严格限制，例如数据库中的字段只保存很短的描述、模板片段或者结构化文本，VARCHAR也可以使用。关键并不是“文章一定使用TEXT”，而是字段容量是否可控，以及该字段是否需要承担索引、排序和过滤等数据库任务。

另一个常见误区是认为VARCHAR一定比TEXT快。实际查询性能不能只由字段类型决定。一个没有索引的VARCHAR字段，同样可能需要扫描大量记录；一个经过合理设计并使用FULLTEXT索引的TEXT字段，在适合的搜索场景下反而可能更加有效。真正影响性能的因素包括查询条件、索引设计、返回数据量、行大小、Buffer Pool命中情况、磁盘IO以及SQL执行计划。

因此，对于文章列表页面尤其需要注意SELECT字段。假设网站首页只需要显示标题、摘要、时间和缩略图，就没有必要每次查询都把几十KB甚至几百KB的正文一起取出来。可以采用类似下面的查询：

SELECT id, title, summary, created_at
FROM articles
WHERE status = 1
ORDER BY created_at DESC
LIMIT 20;

进入文章详情页以后，再根据id读取正文。这样做通常比纠结“VARCHAR还是TEXT哪个快”更加有实际意义。

utf8mb4也是文章系统设计中应该统一考虑的问题。中文、英文、数字、Emoji以及部分扩展字符的存储长度并不相同，因此数据库设计时应该把字符长度和字节长度区分开来。尤其是在计算VARCHAR最大容量、索引长度以及复合索引时，不能简单按照“一个中文字符占3个字节”作为永久规则。

对于日志字段也不能机械地套用TEXT。例如日志通常还需要考虑创建时间、级别、来源模块、请求ID、用户ID等结构化字段。如果日志主要用于检索和分析，把所有信息塞进一个TEXT字段会增加后续查询和分析成本。真正的大规模日志系统通常还会结合专门的日志采集、索引和分析系统。

至于COMPRESS()函数，也不应该作为文章表的常规“优化方案”。数据库内压缩字符串会增加CPU计算成本，并可能影响SQL层面的处理方式。对于普通新闻正文，首先应该解决字段类型、索引、查询列选择、分页和数据访问模式，而不是一看到TEXT就调用COMPRESS()。

同样，不建议把ROW_FORMAT=COMPACT作为现代InnoDB文章表的通用优化配置。具体行格式应该结合MySQL版本、存储引擎以及实际数据访问模式决定。现代MySQL环境通常应优先采用默认且经过验证的InnoDB配置，而不是为了一个TEXT字段强行指定旧的行格式。

如果是新闻网站或者CMS，实际设计通常非常清楚：title、slug、source、category、status等短字段使用VARCHAR等适合索引的类型；summary可以使用VARCHAR；正文使用TEXT或MEDIUMTEXT；发布时间、状态、分类和其他高频过滤字段建立合适的索引；全文搜索需求则单独设计FULLTEXT或搜索引擎方案。

因此，VARCHAR和TEXT并不存在简单的“谁性能更好”。VARCHAR的优势在于长度可控、适合普通索引和结构化字段；TEXT的优势在于能够自然承载较长正文，并避免为了预留大量容量而把所有字段设计成超大的VARCHAR。对于绝大多数新闻、博客和CMS系统，文章标题使用VARCHAR、摘要使用VARCHAR、正文使用TEXT或MEDIUMTEXT，是更加符合实际数据库设计的方法。

数据库字段类型真正应该服从业务数据的生命周期，而不是服从一个固定的“性能排行榜”。文章正文会不断增长、修改、搜索和展示，数据库设计的重点应该放在数据访问方式、索引策略和查询计划上。字段类型只是整个存储设计中的一个环节，选对它可以减少后续维护麻烦，但真正决定系统能否稳定扩展的，往往是表结构、索引和SQL访问模式。