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

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

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

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

Generally speaking; Start out with the most expensive datatype that has the least constraints. Put it in production. If performance starts to be an issue, find out what's actually being stored in those nvarchar columns. Is there any characters in there that wouldn't fit into varchar? If not, switch to varchar. Don't try to pre-optimize before you know where the pain is. My guess is that the choice between nvarchar/varchar is not what's going to slow down your application in the foreseable future. There will be other parts of the application where performance tuning will give you much more bang for the bucks.

如果您使用NVARCHAR只是因为系统存储过程需要它，最常见的情况是莫名其妙的sp_executesql，并且您的动态SQL非常长，那么从性能角度来看，您最好在VARCHAR中进行所有字符串操作(连接、替换等)，然后将最终结果转换为NVARCHAR并将其输入到proc参数中。所以，不要总是使用NVARCHAR!

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

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

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

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