在今天的国际化世界中，nvarchar非常有意义。 对于指定不使用 unicode 的数据，varchar可能很有意义（也许您有一些系统字段需要使用 ASCII）。

我会默认使用 nvarchar 来存储姓名、描述、地址等信息。

varchar 更小，因此相比于 nvarchar，可能会节省一些 IO（但注意字符编码问题可能会变得更加重要）。

还有，看看这个问题：VARCHAR vs NVARCHAR性能。

就我个人而言，我建议使用varchar（正如我在这个帖子中所回答的）。这会带来一定的性能开销。

我们几乎所有的东西都使用VARCHAR，只有在极少数情况下才使用NVARCHAR。

产品代码不需要NVarchar-我们不允许除A-Z、0-9和"_"以外的任何字符在其中...

它的存储空间是原来的两倍，但每个索引页面（和数据页面）的条目数量也只有原来的一半，同时内存高速缓存也浪费了一半，需要更多的CPU周期来比较数据等等。

在IME中，常用的外语口音在Varchar（即LATIN-1）中完美适用。我们没有计划使用中文或其他备选字符集，如果我们需要，从一开始就使用NVarchar来处理字符集将是我们最不用担心的问题——从右到左或垂直对齐文本？:(

如果你允许NVarchar，比如姓名，你如何从键盘中输入扩展字符？如果你导入数据（所以它已经是NVarchar），你如何能够使用你的标准QWERTY键盘搜索该客户。国际化应用程序涉及大量工作，所以我的观点是，“允许使用NVarchar”是没有意义的。

但是，我去的很多地方都有NVarchar ...大多数列也有50个字符宽....他们一定知道有关邮政编码的人口增长和扩张计划的事情，我却不知道！！

是的，性能方面还有大小方面。nvarchar需要更多的字节，我认为它是双倍的（如果我错了请纠正我），这是因为它支持Unicode。所以如果你不需要Unicode支持，就用普通的varchar就可以了。

正如之前提到的，权衡利弊是未来可扩展性与性能之间的选择。根据我的经验，SQL Server在低CPU和内存限制方面表现相当不错，但是如果将其与缓慢的磁盘I/O结合使用，则可能会表现得很差。

如果您没有使用双字节字符集（即中文字符）的计划，请继续使用VARCHAR (MAX)。

一般而言，从约束最小的最昂贵的数据类型开始。将其投入生产。如果性能成为问题，了解实际存储在这些nvarchar列中的内容。里面有任何不适合varchar的字符吗？如果没有，切换到varchar。在知道痛点之前不要尝试进行预优化。我猜测选择nvarchar / varchar不会在可预见的未来拖慢您的应用程序。应用程序的其他部分将有更多的性能调整空间。