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

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

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

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

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

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

I can speak from experience on this, beware of nvarchar. Unless you absolutely require it this data field type destroys performance on larger database. I inherited a database that was hurting in terms of performance and space. We were able to reduce a 30GB database in size by 70%! There were some other modifications made to help with performance but I'm sure the varchar's helped out significantly with that as well. If your database has the potential for growing tables to a million + records stay away from nvarchar at all costs.

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.