我正在使用 SQL Server 2005 开发学校的小型Web应用程序的数据库。
在使用 varchar 和 nvarchar 的问题上，我看到了几种不同的观点：
varchar，否则使用 nvarchar。nvarchar。我开始看到第二个观点的优点。我知道 nvarchar 占用的空间是 varchar 的两倍，但考虑到这只会为几百名学生存储数据，这并不是一个很大的问题。对我来说，似乎最容易的方法是不用担心它，让所有内容都使用 nvarchar。还是有什么我没注意到的吗？
磁盘空间不是问题……但内存和性能会成为问题。页面读取量翻倍、索引大小翻倍、LIKE 和 = 常数行为奇怪等。
您需要存储中文等脚本吗？是或否……
来自 MS BOL 的"Unicode 存储和性能影响"。
编辑：
最近的 SO 问题突出了 nvarchar 性能有多差……
始终使用nvarchar。
大多数应用程序可能永远不需要双字节字符。 但是，如果您需要支持双字节语言，并且数据库模式仅支持单字节，则返回并在整个应用程序中进行修改的成本真的很高昂。
将一个应用程序从varchar迁移到nvarchar的成本要比在大多数应用程序中所需的一点额外磁盘空间要高得多。
NVARCHAR？你不是在为EMC或Oracle工作，对吧？;-) - Solomon Rutzky保持一致性！将VARCHAR和NVARCHAR连接在一起会极大地影响性能。
nvarchar 连接到 varchar 和将 nvarchar 转换为 varchar 并连接到 varchar 之间没有实质性的区别。除非您指的是在列数据类型上保持一致，而不是在连接上保持一致。 - ajehVARCHAR和NVARCHAR时看到了明显的性能下降，那应该是由于对VARCHAR列进行索引以及用于该列（因此索引）的排序规则的类型。我在以下博客文章中详细介绍了这个主题：混合使用VARCHAR和NVARCHAR类型时对索引的影响。 - Solomon Rutzkynvarchar会在内存、存储、工作集和索引方面产生极大的开销，所以如果规格确定它确实永远不必要，那就不要浪费精力。
我不会有一个坚定的“总是使用nvarchar”的规则，因为在许多情况下，它可能是完全浪费资源的 - 特别是从ASCII/EBCDIC或标识符和代码列进行ETL时，这些通常是主键和外键。
另一方面，有许多列的情况下，我会确保在早期提出该问题，如果没有立即得到一个明确的答案，我会将该列设置为nvarchar。
虽然已经有不少答案了，但我还是要说几点，因为有些问题并没有得到解决，或者没有清楚地表达。
首先：不要总是使用NVARCHAR。这是一种非常危险、而且经常很昂贵的态度和方法。同样也不应该说“从不使用游标”，因为它们有时是解决特定问题最有效的手段，而且常见的用WHILE 循环代替游标的方法通常比正确地实现一个游标更慢。
你唯一能使用“始终”这个词的时候是建议“始终做最适合情况的事情”。当你试图在短期开发时间（经理：“我们需要这个功能——你直到刚才才知道——一周前！”）与长期维护成本（最初迫使团队在3周之内完成3个月项目的经理：“为什么我们会遇到这些性能问题？我们怎么可能做出没有灵活性的X？我们不能承受几周的停顿去修复这个问题。我们本周能做些什么来回到我们的优先事项？我们肯定需要花更多时间进行设计，以免这种情况持续发生！”）之间取得平衡时，这可能很难确定。
其次：@gbn的答案涉及到在某些数据建模决策上考虑的一些重要问题。但还有更多需要考虑的因素：
第三点：尽管一些答案错误地关注了“这是一个小应用程序”的方面，而一些答案正确地建议“使用适当的内容”，但是没有一个答案为O.P.提供了真正的指导。在问题中提到了一个重要细节，即这是他们学校的网页。很好！因此我们可以建议：
NCHAR和NVARCHAR字段中的Unicode数据。影响因素如下：
NCHAR(1 - 4000)和NVARCHAR(1 - 4000)使用标准的Unicode压缩方案，但仅支持从SQL Server 2008 R2开始，并且仅适用于行内数据，而不是溢出数据！这似乎比常规的ROW / PAGE压缩算法更好。
NVARCHAR(MAX)和XML（我猜也包括VARBINARY(MAX)、TEXT和NTEXT）的行内数据可以至少进行PAGE压缩，但不能进行ROW压缩。当然，PAGE压缩取决于行内值的大小：我测试了VARCHAR(MAX)，发现6000个字符/字节的行无法压缩，但4000个字符/字节的行可以。
任何溢出数据，LOB或OVERLOW = 没有压缩！
如果使用SQL Server 2005或2008 - 2016 RTM且不使用企业版，则可以有两个字段：一个VARCHAR和一个NVARCHAR。例如，假设您正在存储大多数都是基本ASCII字符（值为0 - 127）的URL，并且有时具有Unicode字符。您的模式可以包括以下3个字段：
...
URLa VARCHAR(2048) NULL,
URLu NVARCHAR(2048) NULL,
URL AS (ISNULL(CONVERT(NVARCHAR([URLa])), [URLu])),
CONSTRAINT [CK_TableName_OneUrlMax] CHECK (
([URLa] IS NOT NULL OR [URLu] IS NOT NULL)
AND ([URLa] IS NULL OR [URLu] IS NULL))
);
在这个模型中，你仅从计算列[URL]中进行SELECT。对于插入和更新操作，需要确定使用哪个字段，方法是看转换是否会更改传入的值，而这个值必须是NVARCHAR类型：
INSERT INTO TableName (..., URLa, URLu)
VALUES (...,
IIF (CONVERT(VARCHAR(2048), @URL) = @URL, @URL, NULL),
IIF (CONVERT(VARCHAR(2048), @URL) <> @URL, NULL, @URL)
);
VARBINARY(MAX)，然后在输出时解压缩:
COMPRESS 和 DECOMPRESS 函数，它们也是 GZip。VARCHAR / CHAR 数据类型中 UTF-8 的本机支持。目前存在太多缺陷使其无法使用，但如果修复了这些缺陷，则这是一些情况下的选项。请参阅我的帖子“SQL Server 2019 中的本机 UTF-8 支持：救世主还是伪先知？”，详细分析了这个新功能。针对您的应用程序，使用nvarchar是可以的，因为数据库大小很小。但是说“总是使用nvarchar”是极其简化的。如果不需要存储像汉字或其他特殊字符等东西，可以使用VARCHAR，它将占用更少的空间。我现在的前任在设计时没有必要使用NVARCHAR。我们最近将其切换到VARCHAR，并仅在该表上就节省了15 GB（它被频繁写入）。此外，如果您在该表上创建索引并且想要包括该列或创建复合索引，则会使索引文件大小变大。
只需在决策时慎重考虑；在SQL开发和数据定义中似乎很少有“默认答案”（当然要尽量避免使用游标）。
由于您的应用程序规模较小，使用nvarchar而不是varchar实际上不会产生明显的成本增加，并且如果需要存储Unicode数据，这样可以避免未来可能出现的麻烦。
一般而言，首先选用最昂贵且限制最少的数据类型。将其投入生产环境。如果性能成为问题，查找实际存储在 nvarchar 列中的内容。其中是否包含不适用于 varchar 的字符？如果没有，则转换为 varchar。在确定痛点之前不要尝试预优化。我猜测，在可预见的未来，nvarchar/varchar 选择不会拖慢您的应用程序。在应用程序的其他部分进行性能调整会带来更多的效益。
我可以从经验中说出来，要小心使用 nvarchar。除非您绝对需要它，否则这种数据字段类型会破坏大型数据库的性能。我继承了一个在性能和空间方面受到影响的数据库。我们能够将一个30GB的数据库大小减少70％！虽然还有一些其他的修改帮助了性能，但我相信 varchar 也对此起了显著的作用。如果您的数据库有可能增长到一百万条或更多记录，请千万不要使用 nvarchar。
NVARCHAR”，这样做可能对性能和硬件成本/预算产生非常负面的影响。少数行，甚至几千行都没有关系，但系统增长速度比人们预期的更快，所以目前接受的答案是对社区的不利影响。谢谢。 - Solomon Rutzky