许多人指出，如果知道值的确切长度，使用CHAR会有一些好处。但是，虽然今天将美国州存储为CHAR(2)很棒，但当您从销售人员那里收到“我们刚刚完成了对澳大利亚的第一笔销售”的消息时，您将陷入痛苦的世界。我总是高估我认为字段需要多长时间，而不是做一个“准确”的猜测来覆盖未来的事件。VARCHAR将在这方面给我更多的灵活性。

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

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

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

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

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

许多人指出，如果知道值的确切长度，使用CHAR会有一些好处。但是，虽然今天将美国州存储为CHAR(2)很棒，但当您从销售人员那里收到“我们刚刚完成了对澳大利亚的第一笔销售”的消息时，您将陷入痛苦的世界。我总是高估我认为字段需要多长时间，而不是做一个“准确”的猜测来覆盖未来的事件。VARCHAR将在这方面给我更多的灵活性。

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