PostgreSQL VARCHAR

学习目标

深入理解 VARCHAR 在 PostgreSQL 中的存储机制，特别是其与 TEXT 类型的等价性
掌握 VARCHAR(n) 长度约束的实际作用及其对应用层与数据库层的影响
辨析 CHAR、VARCHAR 和 TEXT 在性能、存储及维护成本上的细微差别
学习国内互联网大厂在数据库设计规范中关于字符串类型的最佳实践

什么是 VARCHAR 类型

VARCHAR（Variable Character）是关系型数据库中最常用的字符串数据类型之一。在 PostgreSQL 中，它用于存储可变长度的字符序列。

定义语法通常有两种形式：

带长度限制：VARCHAR(n)，其中 n 是允许存储的最大字符数。
无长度限制：VARCHAR（等同于 TEXT），不限制最大长度（受限于 PostgreSQL 的最大字段大小限制，通常为 1GB）。

当向 VARCHAR(n) 插入数据时，如果字符串长度超过 n，PostgreSQL 会抛出错误。如果长度小于 n，则只存储实际字符，不会像 CHAR 那样填充空格。

基本语法

-- 创建一个包含可变长度用户名的表，限制最大 50 字符
CREATE TABLE users (
    user_id SERIAL PRIMARY KEY,
    username VARCHAR(50),
    bio TEXT -- 无长度限制的简介
);

-- 合法插入
INSERT INTO users (username, bio) VALUES ('Alice', 'A short bio');

-- 非法插入：长度超过 50
-- 以下语句将报错：value too long for type character varying(50)
INSERT INTO users (username, bio) VALUES ('ThisUsernameIsWayTooLongForTheDefinedLimitInDatabase', 'Bio');

VARCHAR 与 TEXT、CHAR

在 PostgreSQL 中，VARCHAR、TEXT 和 CHAR 之间的关系与其他数据库（如 MySQL 或 Oracle）有显著不同。理解这一点是掌握 PostgreSQL 字符串处理的关键。

核心结论：VARCHAR 与 TEXT 几乎相同

在 PostgreSQL 内部实现中，不带长度限制的 VARCHAR 和 TEXT 是完全等价的。它们使用相同的内部数据结构（varlena），具有相同的性能表现，且都没有长度上限（除了系统级的 1GB 限制）。即使是带长度限制的 VARCHAR(n)，其底层存储机制也与 TEXT 基本一致，唯一的区别在于数据库会在写入时多做一个长度检查的步骤。

类型对比

特性	CHAR(n)	VARCHAR(n)	TEXT / VARCHAR
存储方式	固定长度，自动补空格	可变长度，存实际内容 + 长度头	可变长度，存实际内容 + 长度头
长度检查	强制固定，超长报错	写入时检查上限，超长报错	无上限检查
空格行为	查询比较时忽略尾随空格	严格保留空格	严格保留空格
修改成本	修改长度需重写表（高成本）	修改长度需重写表（高成本）	无需修改，天然支持任意长度
推荐指数	⭐ (仅限特定场景)	⭐⭐⭐ (传统习惯)	⭐⭐⭐⭐⭐ (PostgreSQL 首选)

国内开发者倾向于 TEXT

在国内的 PostgreSQL 社区及阿里、腾讯等大厂的开发规范中，普遍建议直接使用 TEXT 代替 VARCHAR(n)，原因如下：

避免锁表风险：如果需要将 VARCHAR(50) 扩容到 VARCHAR(100)，在旧版本 PostgreSQL 或高并发场景下，可能需要重写整个表（Rewrite Table），导致长时间锁表，影响业务可用性。而 TEXT 无需此操作。
性能无差异：基准测试表明，VARCHAR(n) 的长度检查带来的 CPU 开销微乎其微，但在应用层进行长度校验往往更灵活、更高效。
简化迁移：从其他数据库迁移时，TEXT 兼容性更好，无需纠结具体的长度数字。

存储机制与长度约束

很多初学者认为定义 VARCHAR(255) 会比 TEXT 节省空间或提高速度，这在 PostgreSQL 中是一个误区。

变长数据存储结构

PostgreSQL 使用一种称为 "Varlena"（Variable Length Array）的结构来存储变长数据。

头部信息：每个变长字段前都有一个头部（通常 1-4 字节），用于记录数据的实际长度。
实际数据：紧接着头部存储真实的字符内容。
TOAST 机制：当字段数据非常大（默认超过 2KB）时，PostgreSQL 会自动将其压缩或存储到单独的 TOAST 表中，主表只保留指针。这对 VARCHAR 和 TEXT 同样有效。

因此，VARCHAR(100) 存储 "Hi" 时，占用的空间与 TEXT 存储 "Hi" 完全一样（都是 "Hi" 的字节数 + 头部开销），不会预先分配 100 字节的空间。

长度约束的代价

虽然 VARCHAR(n) 提供了数据完整性约束，但它也带来了维护上的负担：

DDL 变更困难：如前所述，修改 n 的值可能触发全表重写。
应用层重复校验：即使数据库定义了 VARCHAR(50)，负责任的后端代码通常也会在 API 入口层再次校验长度，以便返回更友好的错误提示。这意味着数据库层的约束在某些场景下显得冗余。

性能分析与索引优化

在涉及大量字符串查询的场景下，VARCHAR 的性能表现如何？

查询性能

相等性查询：VARCHAR 和 TEXT 在 = 操作符下的性能完全一致。
模糊查询：在使用 LIKE 'prefix%' 时，两者性能也相同。如果在这些字段上建立了 B-Tree 索引，前缀匹配可以利用索引加速。
排序操作：排序开销主要取决于字符串的实际长度和内容，与声明的类型（VARCHAR vs TEXT）无关。

索引注意事项

索引体积：索引的大小取决于实际存储的数据长度，而不是声明的最大长度。因此，定义 VARCHAR(1000) 并不会让索引变大，除非你真的存入了接近 1000 字符的数据。
最左前缀原则：对于 VARCHAR 和 TEXT 字段，B-Tree 索引支持最左前缀匹配。这对于搜索用户名、商品编码等场景非常高效。
哈希索引：如果只需要做等值查询（=），可以考虑使用 Hash 索引，它在处理长字符串等值比较时可能比 B-Tree 更快，但需注意 Hash 索引不支持范围查询和模糊匹配。

性能测试结论

根据 PostgreSQL 官方文档及社区基准测试：

"There is no performance difference among these three types (char, varchar, text), apart from increased storage space when using blank-padded char."

翻译过来就是：除了 CHAR 因为空格填充会浪费空间外，CHAR、VARCHAR 和 TEXT 之间没有性能差异。

最佳实践

基于上述分析，以下是针对 PostgreSQL VARCHAR 类型的实战建议：

1. 优先使用 TEXT

除非你有非常特殊的理由（例如需要严格遵循旧版 SQL 标准或配合特定的 ORM 框架行为），否则在新建表时，一律使用 TEXT。

它消除了“该设多少长度”的纠结。
它避免了未来扩容的 DDL 风险。
它的性能与 VARCHAR 无异。

2. 何时使用 VARCHAR

仅在以下场景考虑使用 VARCHAR(n)：

强合规要求：某些行业标准或遗留系统明确要求数据库层面必须限制长度。
数据清洗：作为最后一道防线，防止应用程序 Bug 写入异常长的垃圾数据（但建议配合 CHECK 约束使用）。

3. 避免 CHAR

再次强调，除非是存储定长的哈希值（如 MD5、SHA）、国家代码或状态标志，否则不要使用 CHAR。空格填充带来的隐式 Bug 修复成本远高于其带来的微小便利。

4. 国际化与编码

PostgreSQL 默认支持 UTF-8 编码。VARCHAR 和 TEXT 都能完美存储中文、Emoji 等多字节字符。

注意：VARCHAR(n) 中的 n 指的是字符数，而不是字节数。
例如：VARCHAR(5) 可以存储 "你好呀"（3 个字符，6-9 个字节），但不能存储 "你好呀世界"（5 个字符，刚好满）再多加一个字符。

总结

等价性：在 PostgreSQL 中，TEXT 和 VARCHAR（无限制）在底层是完全相同的；VARCHAR(n) 仅多了一个长度检查约束。
存储机制：三者均采用变长存储，VARCHAR(n) 不会预分配空间，不会浪费存储。
性能表现：TEXT、VARCHAR 和 CHAR（不含填充开销）在查询和索引性能上没有显著差异。
维护成本：VARCHAR(n) 修改长度可能引发全表重写，维护成本高；TEXT 最灵活。
行业共识：国内 PostgreSQL 最佳实践推荐默认使用 TEXT，将长度校验逻辑移至应用层或使用 CHECK 约束。