SQL 中的 CHAR 数据类型是否已过时？你什么时候使用它？答案

【问题标题】：Is the CHAR datatype in SQL obsolete? When do you use it?SQL 中的 CHAR 数据类型是否已过时？你什么时候使用它？
【发布时间】：2010-10-20 00:16:13
【问题描述】：

标题几乎是问题的框架。我已经好几年没用过 CHAR 了。现在，我正在对一个全是 CHAR 的数据库进行逆向工程，用于主键、代码等。 CHAR(30) 列怎么样？

编辑：因此，普遍的看法似乎是 CHAR 如果对某些事情完全没问题。但是，我认为您可以设计一个不需要“这些特定事物”的数据库模式，因此不需要固定长度的字符串。使用 bit、uniqueidentifier、varchar 和 text 类型，似乎在一个规范化的模式中，您会获得某种优雅，而这是使用编码字符串值时所没有的。从固定角度思考，没有冒犯的意思，似乎是大型机时代的遗物（我自己学过 RPG II）。我相信它已经过时了，而且我没有听到你声称的令人信服的论点。

【问题讨论】：

标签： sql types char

【解决方案1】：

我使用 char(n) 作为代码，使用 varchar(m) 作为描述。 Char(n) 似乎会带来更好的性能，因为当内容大小发生变化时，数据不需要移动。

【讨论】：

【解决方案2】：

如果数据的性质决定了字段的长度，我使用 CHAR。否则为 VARCHAR。

【讨论】：

对，我的意思是：我看不到更多这种性质的数据（除非我自己介绍）。
@cdonner 仍然有很多常用字段，如电话号码、邮政编码、州缩写，它们不是可变长度的。也可能存在内部代码和诸如序列号、部门编号、扩展名、站点 ID、商店编号等字段不可变的内容，并且 CHAR 可以正常工作并且是最佳选择。

【解决方案3】：

在我熟悉的 DBMS 中，CHAR 的处理速度仍然比 VARCHAR 快。它们的固定大小允许使用 VARCHAR 无法进行优化。此外，CHARS 的存储要求略低，因为无需存储长度，假设大多数行需要完全或几乎完全填充 CHAR 列。

CHAR(30) 的影响（以百分比计）比 CHAR(4) 小。

关于用法，我倾向于在以下情况下使用 CHAR：

字段通常总是接近或达到最大长度（股票代码、员工 ID 等）；或
长度很短（小于 10）。

在其他任何地方，我都使用 VARCHAR。

【讨论】：

> 此外，CHARS 的存储要求略低，因为不必存储长度。仅当使用几乎整个分配的长度（基本上是固定大小）时，这才是正确的。否则将添加填充（至少在 Oracle 中），这可能超过存储长度。
好点，蒂洛。虽然我的规则（某种程度上）涵盖了这一点，但我更明确地说明了这一点。
@Pax - 我同意“最大长度”，但不同意“接近”。出于类似的原因，我不同意“少于 10 长度”的东西。无意投反对票。
@Vinegar，如果 VARCHAR 使用 4 个字节作为长度并且所有行浪费的字节数少于 4 个字节，则 CHAR 更好——这就是“接近”注释的来源。 10 个长度只是我个人的偏好，因为 CHAR 更快，每行浪费 10 个字节是无关紧要的（在 my 平台上）。
@Pax - 我不同意

【解决方案4】：

当值的长度固定时，我使用 CHAR。例如，我们正在根据某种算法生成代码或其他东西，该算法返回具有特定固定长度的代码，比如 13。

否则，我发现 VARCHAR 更好。使用 VARCHAR 的另一个原因是，当您在应用程序中取回该值时，您不需要修剪该值。在 CHAR 的情况下，无论值是否完全填充，您都将获得列的完整长度。它会被空格填充，你最终会修剪每个值，而忘记这会导致错误。

【讨论】：

【解决方案5】：

对于 PostgreSQL，文档指出char() 在存储空间上没有varchar() 的优势；唯一的区别是它被空白填充到指定的长度。

话虽如此，我仍然使用char(1) 或char(3) 作为一字符或三字符代码。我认为，即使没有存储或性能优势，由于指定列应包含的类型的清晰度提供了价值。是的，我通常也使用检查约束或外键约束。除了这些情况，我通常只使用text 而不是使用varchar()。同样，这是由数据库实现通知的，如果值足够大，它会自动从内联存储切换到外联存储，而其他一些数据库实现则不这样做。

【讨论】：

【解决方案6】：

Char 并没有过时，它只应该在字段的长度不应该改变的情况下使用。在平均数据库中，这将是非常少的字段，主要是某种代码字段，例如州缩写，如果您使用邮政编码，则它是标准的 2 字符字段。在字段长度可变的情况下使用 Char 意味着将进行大量修剪，这是额外的、不必要的工作，并且应该重构数据库。

【讨论】：