我会选择varchar，除非列存储固定的值，如美国州代码-这总是2个字符长，有效的美国州代码列表不经常改变:)。

在其他情况下，甚至像存储哈希密码(固定长度)，我会选择varchar。

为什么——char类型的列总是用空格填充，这使得列my_column定义为char(5)，值为'ABC'在比较中:

my_column = 'ABC' -- my_column stores 'ABC  ' value which is different then 'ABC'

假的。

这个特性可能会在开发过程中导致许多恼人的bug，并使测试更加困难。

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

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

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

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

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

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

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

当使用varchar值时，SQL Server每行需要额外的2个字节来存储关于该列的一些信息，而如果使用char则不需要 所以除非你

我支持吉姆·麦基思的评论。

此外，如果您的表只有CHAR列，那么索引和全表扫描会更快。基本上，优化器将能够预测每条记录有多大，如果它只有CHAR列，而它需要检查每个VARCHAR列的大小值。

此外，如果您将VARCHAR列更新到比其先前内容更大的大小，则可能会强制数据库重新构建其索引(因为您强制数据库将记录物理地移动到磁盘上)。而对于CHAR列，这种情况永远不会发生。

但是，除非表很大，否则您可能不会关心性能受到的影响。

记住吉布拉的至理名言。早期的性能优化是万恶之源。