Nvarchar将在内存、存储、工作集和索引方面有很大的开销，所以如果规格规定它真的永远都不需要，那就别费心了。

我不会有一个硬性的“总是nvarchar”规则，因为它在许多情况下完全是浪费——特别是来自ASCII/EBCDIC的ETL或标识符和代码列，它们通常是键和外键。

另一方面，有很多列的情况，在这些情况下，我肯定会在早期提出这个问题，如果我没有立即得到一个明确而快速的答案，我将使列为nvarchar。

在过去的几年里，我们所有的项目都使用了NVARCHAR，因为所有这些项目都是多语言的。从外部源导入的数据(例如ASCII文件等)在插入到数据库之前被上转换为Unicode。

我还没有遇到任何与较大索引相关的性能问题，等等。索引确实会使用更多的内存，但是内存很便宜。

无论您是使用存储过程还是动态构造SQL，都要确保所有字符串常量都有N前缀(例如SET @foo = N' hello world.';)，这样常量也是Unicode。这避免了在运行时进行任何字符串类型转换。

YMMV。

在某些特殊情况下，您会有意限制数据类型，以确保它不包含某个特定集合中的字符。例如，我有一个场景，我需要在数据库中存储域名。域名的国际化在当时是不可靠的，所以最好限制在基础水平上的输入，并有助于避免任何潜在的问题。

是一致的!加入一个VARCHAR到NVARCHAR有一个很大的性能打击。

为什么在所有这些讨论中，没有提到UTF-8?能够存储完整的unicode字符跨度并不意味着必须总是为每个字符分配两个字节(或使用unicode术语的“码位”)。所有的ASCII都是UTF-8。SQL Server检查VARCHAR()字段，文本是严格的ASCII(即顶部字节位零)?我希望不是。

如果您希望存储unicode并希望与旧的仅使用ascii的应用程序兼容，我认为使用VARCHAR()和UTF-8将是神奇的子弹:它只在需要时使用更多的空间。

对于那些不熟悉UTF-8的人，我可以推荐一个入门。

我在工作中经常遇到这样的问题:

库存和定价的FTP提要-当varchar工作正常时，项目描述和其他文本是在nvarchar中。将这些文件转换为varchar可以将文件大小减少近一半，并且对上传非常有帮助。 上面的场景工作得很好，直到有人在商品描述中添加了一个特殊字符(可能是商标，不记得了)

我还是不会每次都用varchar。如果有任何疑问或特殊字符的潜力，我使用nvarchar。我发现，当我100%控制填充字段的内容时，我主要使用varchar。