总是使用nvarchar。

对于大多数应用程序，您可能永远都不需要双字节字符。但是，如果您需要支持双字节语言，而您的数据库模式中只有单字节支持，那么返回并在整个应用程序中进行修改是非常昂贵的。

将一个应用程序从varchar迁移到nvarchar的成本将远远超过在大多数应用程序中使用的一点点额外磁盘空间。

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

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

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

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

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

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

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

YMMV。

磁盘空间不是问题…但是记忆和性能会。 双倍的页面阅读量，双倍的索引大小，奇怪的LIKE和=恒定的行为等等

你需要存储中文等脚本吗?是或不是…

来自MS BOL的《Unicode的存储和性能影响》

编辑:

最近的SO问题强调了nvarchar性能有多差…

SQL Server在搜索nvarchar字符串时使用高CPU

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