标题几乎构成了这个问题。我已经好几年没用过 CHAR 了。现在，我正在对一个全是 CHAR 的数据库进行逆向工程，用于主键、代码等。CHAR(30) 列怎么样？
编辑：所以一般的意见似乎是 CHAR 如果对某些事情完全没问题。但是，我认为您可以设计一个不需要“这些特定事物”的数据库模式，因此不需要固定长度的字符串。使用 bit、uniqueidentifier、varchar 和 text 类型，似乎在一个规范化的模式中，您会获得某种优雅，而这是使用编码字符串值时所没有的。从固定角度思考，没有冒犯的意思，似乎是大型机时代的遗物（我自己学过 RPG II）。我相信它已经过时了，而且我没有听到你声称的令人信服的论点。
我使用 char(n) 作为代码，使用 varchar(m) 作为描述。Char(n) 似乎会带来更好的性能，因为当内容大小发生变化时，数据不需要移动。
在我熟悉的 DBMS 中，CHAR 的处理速度仍然比 VARCHAR 快。它们的固定大小允许使用 VARCHAR 无法进行优化。此外，CHARS 的存储要求略低，因为无需存储长度，假设大多数行需要完全或几乎完全填充 CHAR 列。
与 CHAR(4) 相比，使用 CHAR(30) 的影响较小（以百分比计）。
至于用法，我倾向于在以下情况下使用 CHAR：
在其他任何地方，我都使用 VARCHAR。
如果数据的性质决定了字段的长度，我使用 CHAR。否则为 VARCHAR。
当值的长度固定时，我使用 CHAR。例如，我们正在生成一个代码或基于某种算法的代码，该算法返回具有特定固定长度的代码，比如 13。
否则，我发现 VARCHAR 更好。使用 VARCHAR 的另一个原因是，当您在应用程序中取回该值时，您不需要修剪该值。在 CHAR 的情况下，无论值是否完全填充，您都将获得列的完整长度。它会被空格填充，你最终会修剪每个值，而忘记这会导致错误。
对于 PostgreSQL，文档指出char()在存储空间上没有优势varchar(); 唯一的区别是它被空白填充到指定的长度。
话虽如此，我仍然将char(1)orchar(3)用于一字符或三字符代码。我认为，即使没有存储或性能优势，由于指定列应包含内容的类型的清晰度提供了价值。是的，我通常也使用检查约束或外键约束。除了这些情况，我通常只是坚持text而不是使用varchar(). 同样，这是由数据库实现通知的，如果值足够大，它会自动从内联存储切换到外联存储，而其他一些数据库实现则不这样做。
Char 并没有过时，它只应该在字段的长度不应该改变的情况下使用。在平均数据库中，这将是非常少的字段，主要是某种代码字段，例如州缩写，如果您使用邮政编码，则它是标准的 2 字符字段。在字段长度可变的情况下使用 Char 意味着将进行大量修剪，这是额外的、不必要的工作，并且应该重构数据库。