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

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

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

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

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

城市名字性别| |

鲍勃| |洛杉矶

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

城市名称|

鲍勃|西雅图

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

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

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

一般规则是，如果所有行的长度接近相同，则选择CHAR。当长度变化显著时，选择VARCHAR(或NVARCHAR)。CHAR也可能更快一些，因为所有的行都是相同的长度。

它因数据库实现而异，但通常，VARCHAR(或NVARCHAR)除了实际数据之外，还会使用一到两个字节的存储空间(用于长度或终止)。因此(假设您使用的是单字节字符集)存储单词“FooBar”

CHAR(6) = 6字节(无开销) VARCHAR(100) = 8字节(2字节开销) CHAR(10) = 10字节(4字节浪费)

最重要的是，对于相对相同长度的数据(在两个字符长度差以内)，CHAR可以更快、更节省空间。

注意:Microsoft SQL对于一个VARCHAR有2个字节的开销。这可能因DB而异，但通常至少需要1个字节的开销来指示VARCHAR上的长度或EOL。

正如Gaven在评论中指出的:当涉及到多字节字符集时，情况会发生变化，在这种情况下VARCHAR会成为更好的选择。

关于VARCHAR声明长度的注意事项:因为它存储了实际内容的长度，所以您不会浪费未使用的长度。因此，在VARCHAR(6)、VARCHAR(100)或VARCHAR(MAX)中存储6个字符使用相同的存储量。阅读更多关于使用VARCHAR(MAX)时的差异。在VARCHAR中声明最大大小以限制存储的容量。

在评论中AlwaysLearning指出Microsoft Transact-SQL文档似乎说的恰恰相反。我认为这是一个错误，或者至少文件不清楚。

There are performance benefits, but here is one that has not been mentioned: row migration. With char, you reserve the entire space in advance.So let's says you have a char(1000), and you store 10 characters, you will use up all 1000 charaters of space. In a varchar2(1000), you will only use 10 characters. The problem comes when you modify the data. Let's say you update the column to now contain 900 characters. It is possible that the space to expand the varchar is not available in the current block. In that case, the DB engine must migrate the row to another block, and make a pointer in the original block to the new row in the new block. To read this data, the DB engine will now have to read 2 blocks. No one can equivocally say that varchar or char are better. There is a space for time tradeoff, and consideration of whether the data will be updated, especially if there is a good chance that it will grow.

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

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

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

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

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

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

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

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

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

城市名字性别| |

鲍勃| |洛杉矶

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

城市名称|

鲍勃|西雅图

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

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

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