我永远不会使用字符。我和很多人都有过这样的争论，他们总是提出令人厌倦的cliché char更快。我说，快多少?我们在这里讨论的是什么，毫秒，秒，如果是的话，是多少?你是在告诉我，因为有人声称它快了几毫秒，我们就应该在系统中引入大量难以修复的bug ?

这里有一些你会遇到的问题:

每个字段都将被填充，因此您最终得到的代码将永远到处都是RTRIMS。对于较长的字段来说，这也是一种巨大的磁盘空间浪费。

现在假设你有一个典型的例子，一个只有一个字符的char字段，但是这个字段是可选的。如果有人传递一个空字符串到这个字段，它就变成了一个空格。因此，当另一个应用程序/进程查询它时，如果不使用rtrim，它们将得到一个单独的空间。我们有xml文档，文件和其他程序，只显示一个空格，在可选字段和打破东西。

现在你要确保传递给char字段的是空值而不是空字符串。但这不是null的正确用法。这里是null的用法。假设您从供应商那里获得了一个文件

城市名字性别| |

鲍勃| |洛杉矶

如果没有指定性别，则在表中输入Bob、空字符串和Los Angeles。现在让我们假设你得到了文件，它的格式改变了，性别不再包括在内，而是在过去。

城市名称|

鲍勃|西雅图

好吧，现在由于性别不包括在内，我将使用null。Varchars毫无问题地支持这一点。

而夏尔则不同。你总是要发送null。如果你发送空字符串，你将得到一个包含空格的字段。

我可以继续在大约20年的开发过程中修复所有的错误。

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

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

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

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

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

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

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

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

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