使用数据类型“文本”存储字符串有什么缺点吗？

Question

根据PostgreSQL Documentation，它们支持3种数据类型的字符数据：

character varying(n), varchar(n)  variable-length with limit
character(n), char(n)             fixed-length, blank padded
text                              variable unlimited length

在我的应用程序中，我遇到了一些令人不快的情况，其中插入/更新查询失败，因为要插入的所需文本超出了 varchar(n) 或 char(n) 限制。

对于此类情况，将此类列的数据类型更改为text 就足够了。

我的问题是：

• 如果我们将每个字符存储列的数据类型泛化并更改为text，在性能/内存方面是否有任何不利之处？
• 如果数据类型为text 的列每次存储10 个或更少的字符，我应该选择text 还是varchar(10)？
• 如果我选择text 有什么缺点？

Answer 1

一般来说，使用text 在性能/内存方面没有缺点。相反：text 是最优的。其他类型或多或少有相关的缺点。 text 字面意思是 Postgres 类型系统中的 "preferred" type among string types，它会影响函数或运算符类型的解析。

尤其是never use char(n)（character(n) 的别名），除非您知道自己在做什么。 char 或 character 只是 character(1) 的缩写，所以都一样。内部名称是bpchar（代表“空白填充字符”）。该类型仅用于与旧代码和标准兼容。现在已经没什么意义了，浪费内存，很可能会造成麻烦：

• Compare varchar with char
• String field length in Postgres SQL

您可以使用带有长度修饰符的varchar(n)（character varying(n) 的别名）。但是varchar(255) typically indicates a misunderstanding 是从其他 RDBMS 继承而来的，它可能是性能的局部最优值。在 Postgres 中，长度修饰符 (255) 没有特殊含义，很少有意义。

• Should I add an arbitrary length limit to VARCHAR columns?

以后尝试更改varchar(n) 的长度修饰符时，旧版本会导致各种问题。大多数这些问题在现代 Postgres 中都得到了缓解，但没有长度说明符的 text 或 varchar（character varying 的别名）（以及 CHECK constraint 代替）从未遇到任何这些问题。

CHECK 约束与依赖于列类型的依赖视图、函数、FK 约束等一样快且不太可能导致问题。它可以做的不仅仅是强制最大字符长度——任何你可以放入布尔表达式的东西。见：

• Change PostgreSQL columns used in views

最后，还有"char"（带双引号）：用于单个 ASCII 字母的 1 字节数据类型，用作廉价的内部枚举类型。

除了text 在 Postgres 中，我很少使用任何其他字符数据。

Answer 2

你提到的所有数据类型都使用相同的内部表示（比较有名的struct varlena）

CHAR 和 VARCHAR 数据类型只是为此添加了长度检查，并且（在 CHAR 的情况下）具有不同的空格填充语义。

您可以安全地使用TEXT，只要上述任何内容对您的逻辑都不重要。

Answer 3

从您链接到的页面：

“这三种类型之间没有性能差异，除了 从使用空白填充类型时增加的存储空间，以及 几个额外的 CPU 周期来检查存储到 长度受限的列。虽然字符（n）有性能 在其他一些数据库系统中的优势，没有这样的优势 在 PostgreSQL 中；事实上 character(n) 通常是最慢的 三是因为其额外的存储成本。在大多数情况下，文本 或应改用字符变化。”

在 Postgres 中使用 text 数据类型似乎没有任何缺点。

但是，您应该考虑是否真的要允许将大量文本存储在数据库中。将其保留为 varchar 但具有更高的限制可以防止您无意中在数据库中存储大量数据。