如果您和我一起工作，并且使用Oracle，我可能会让您在几乎所有情况下都使用varchar。char比varchar使用更少的处理能力的假设可能是正确的…现在……但是随着时间的推移，数据库引擎会变得更好，这种通用规则将成为未来的“神话”。

另一件事:我从未见过因为有人决定使用varchar而导致性能问题。你将更好地利用你的时间来编写好的代码(对数据库的调用更少)和高效的SQL(索引如何工作，优化器如何做出决策，为什么它比通常更快……)

最后一个想法:我在使用CHAR时看到过各种各样的问题，人们在“应该找‘’的时候找‘’，或者人们在应该找‘FOO(这里有一堆空格)’的时候找‘FOO’，或者人们没有去掉后面的空格，或者Powerbuilder在从Oracle过程中返回的值中添加2000个空格时出现了错误。

Char更快一点，所以如果你知道一个列有一定的长度，就使用Char。例如，存储(M)ale/(F)emale/(U)nknown表示性别，或者存储2个字符表示美国的一个州。

在计算列值实际所需的大小和为Varchar分配空间时，会有一些小的处理开销，因此如果您确实确定值总是多长，那么最好使用Char并避免命中。

这是典型的空间与性能的权衡。

在MS SQL 2005中，Varchar(或每个字符需要两个字节的语言，如中文)是可变长度的。如果您在将行写入硬盘后再添加数据，则会将数据定位在与原始行不相邻的位置，并导致数据文件碎片化。这将影响性能。

所以，如果空间不是问题，那么Char格式的性能更好，但如果你想保持数据库的大小，那么varchars格式更好。

我认为在你的情况下，可能没有理由不选择Varchar。它为您提供了灵活性，正如许多受访者所提到的，现在的性能是这样的，除非在非常特定的情况下，我们普通人(而不是谷歌DBA)不会注意到差异。

当谈到DB类型时，值得注意的一件有趣的事情是sqlite(一个非常受欢迎的迷你数据库，具有相当令人印象深刻的性能)将所有内容作为字符串放入数据库并动态地输入类型。

我总是使用VarChar，通常使它比我可能迫切需要的要大得多。如你所说，为了安全起见，为什么不买50英镑呢?

如果字段中的所有数据值长度相同，则CHAR占用的存储空间比VARCHAR少。现在，在2009年，800GB的数据库与810GB的数据库(如果您将varchar转换为CHARs)在所有用途和目的上是一样的，但对于短字符串(1或2个字符)，CHAR仍然是行业的“最佳实践”。

现在，如果您查看大多数数据库提供的各种各样的数据类型，即使是整数(bit、tiny、int、bigint)，也有理由选择其中一种。每次都简单地选择bigint实际上是对字段的目的和用途有点无知。如果一个字段只是以年为单位表示一个人的年龄，那么使用bigint就太夸张了。现在它不一定是“错误的”，但它不是有效的。

但这是一个有趣的争论，随着数据库的改进，可以说CHAR vs VARCHAR的相关性越来越小。