使用CHAR (NCHAR)和VARCHAR (NVARCHAR)会在数据库服务器存储数据的方式上带来不同。第一个引入了尾随空格;我在SQL SERVER函数中使用LIKE操作符时遇到了问题。因此，我必须始终使用VARCHAR (NVARCHAR)来确保它的安全性。

例如，如果我们有一个表TEST(ID INT, Status CHAR(1))，你写一个函数列出所有具有特定值的记录，如下所示:

CREATE FUNCTION List(@Status AS CHAR(1) = '')
RETURNS TABLE
AS
RETURN
SELECT * FROM TEST
WHERE Status LIKE '%' + @Status '%'

在这个函数中，我们期望当我们输入默认参数时，函数会返回所有的行，但实际上并没有。将@Status数据类型更改为VARCHAR将解决该问题。

在一些SQL数据库中，为了优化偏移量，VARCHAR将被填充到其最大大小，这是为了加速全表扫描和索引。

因此，与CHAR(200)相比，使用VARCHAR(200)并不会节省任何空间。

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

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

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

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

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

城市名字性别| |

鲍勃| |洛杉矶

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

城市名称|

鲍勃|西雅图

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

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

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

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

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

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

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

除了性能方面的好处外，CHAR还可以用来表示所有值都应该是相同的长度，例如，美国州缩写的列。