为什么我不应该在Sql Server中使用NVARCHAR?

在今天的i18n世界里,nvarchar很有意义。varchar对于 不是unicode(可能有些系统字段要求是ASCII)。

默认情况下,我会使用nvarchar来处理名称、描述、地址等。

varchar 瓦查尔 nvarchar (但请注意,代码页也成为一个更大的问题)。

另外,请参见以下问题: VARCHAR vs NVARCHAR performance.

就我个人而言,我说坚持varchar(正如我在这篇文章中所回答的那样)。有一个非常重要的性能开销。

我们几乎每件事都使用VARCHAR,NVARCHAR只是偶尔使用。

产品代码不需要NVarchar-我们不允许除了A-Z,0-9和“u”之外的任何东西。。。

常用的外国口音只能在Varchar(即拉丁语-1)中找到。我们没有计划做中文或其他替代字符集,当我们能够处理从第一天开始使用NVarchar的字符集将是我们最不担心的-从右到左或文本的垂直对齐?? :(

但我又去了很多地方找女巫。。。而且大多数的栏也有50个字符宽。。。。他们必须知道一些关于人口增长和邮政编码扩展计划,我不知道!!

是的,性能,尺寸。nvarchar需要更多字节,我认为它是double(如果我错了,请纠正我),这是因为unicode支持。因此,如果不需要unicode支持,请使用常规的varchar。

如果您不打算使用双字节字符集(即中文字符),请使用VARCHAR(MAX)。

一般来说,从约束最少的最昂贵的数据类型开始。投入生产。如果性能开始成为一个问题,请找出实际存储在nvarchar列中的内容。里面有没有不适合varchar的字符?如果不是,切换到varchar。在你知道痛在哪里之前不要试着预先优化。我的猜测是,在nvarchar/varchar之间的选择并不会在可预见的将来减慢应用程序的速度。在应用程序的其他部分,性能调整将为您带来更大的回报。