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

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

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

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

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

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

编辑:

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

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

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

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

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

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

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

由于您的应用程序很小，使用nvarchar与使用varchar相比，基本上没有明显的成本增加，而且如果您需要存储unicode数据，您也省去了潜在的麻烦。