pgsql text varchar

在 PostgreSQL 中，TEXT 和 VARCHAR 的关系非常有趣，因为它们在很多情况下是完全等价的。

简单来说：如果你不指定长度限制，VARCHAR 和 TEXT 在底层存储和性能上没有任何区别。

为了帮你做出最佳选择，我将从性能、标准和实际应用场景三个维度为你详细拆解。

⚡ 核心结论：性能与存储

首先打破一个常见的误区：TEXT 并不比 VARCHAR 慢，也不占更多空间。

• 底层存储：两者都使用 varlena 结构（变长数据），并且都使用 TOAST 技术来压缩或溢出存储大字段（超过 2KB 时自动处理）。
• 执行计划：PostgreSQL 的查询优化器对待两者的方式完全一致。
• 特殊情况：VARCHAR 只有在指定了长度（如 VARCHAR(50)）时，才会增加一点点 CPU 开销用于长度检查。

📊 详细对比：TEXT vs VARCHAR

特性	TEXT	VARCHAR (无长度限制)	VARCHAR(n) (有长度限制)
SQL 标准	PostgreSQL 特有 (非标准)	SQL 标准	SQL 标准
长度限制	无 (最大 1GB)	无 (最大 1GB)	有 (强制限制 n 个字符)
性能	极快	极快 (与 TEXT 相同)	极快 (但在写入时需检查长度)
主要用途	博客内容、评论、日志	兼容旧系统迁移	用户名、邮箱、手机号等短文本

💡 如何选择？（最佳实践）

在实际开发中，建议遵循以下原则：

1. 默认首选 TEXT

对于大多数自由文本字段（如文章正文、描述、备注），直接使用 TEXT。

• 理由：它语义清晰，表示“这是一段文本，长度不限”。你不需要在未来因为字段长度不够而修改表结构（ALTER TABLE 在大表上是很慢的操作）。

2. 需要约束时使用 VARCHAR(n)

对于有明确业务规则限制的字段，使用带长度的 VARCHAR。

• 场景：手机号（11位）、身份证号、邮编、国家代码。
• 理由：利用数据库的约束能力，防止应用程序出现 Bug 导致写入超长数据。

3. 关于“超过 255 字符”的迷思

你可能听说过“超过 255 字符建议用 TEXT”的说法。

• 在 MySQL 中：这是真的，因为 MySQL 的索引机制对 255 字节以内和以外的处理不同。
• 在 PostgreSQL 中：这是假的。PG 对 TEXT 和 VARCHAR 一视同仁，无论多长，处理方式都一样。

📝 代码示例

CREATE TABLE user_content (
    id SERIAL PRIMARY KEY,
    -- 推荐：用于存储标题，限制长度防止 UI 爆版
    title VARCHAR(100), 
    
    -- 推荐：用于存储正文，无长度焦虑，性能与 VARCHAR 无异
    content TEXT,       
    
    -- 不推荐：除非为了兼容旧系统，否则不要混用
    legacy_field VARCHAR 
);

总结：在 PostgreSQL 中，不要纠结 TEXT 和 VARCHAR 的性能差异。想要限制长度就用 VARCHAR(n)，不限制长度就放心大胆地用 TEXT。