早期性能优化和使用最佳实践类型的规则之间存在差异。如果创建的新表中总是有固定长度的字段，那么使用CHAR是有意义的，在这种情况下应该使用它。这不是早期优化，而是实现经验法则(或最佳实践)。

即-如果你有一个2字母的状态字段，使用CHAR(2)。如果您有一个包含实际州名的字段，请使用VARCHAR。

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

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

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

早期性能优化和使用最佳实践类型的规则之间存在差异。如果创建的新表中总是有固定长度的字段，那么使用CHAR是有意义的，在这种情况下应该使用它。这不是早期优化，而是实现经验法则(或最佳实践)。

即-如果你有一个2字母的状态字段，使用CHAR(2)。如果您有一个包含实际州名的字段，请使用VARCHAR。

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

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

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

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

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

假的。

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

碎片。Char会保留空间，而VarChar则不会。为了适应varchar的更新，可以要求页面分割。