我不应该在 Sql Server 中使用 NVARCHAR 有什么原因吗？答案

【问题标题】：Is there a reason why I shouldn't use NVARCHAR in Sql Server?我不应该在 Sql Server 中使用 NVARCHAR 有什么原因吗？
【发布时间】：2009-02-16 07:50:05
【问题描述】：

我现在正在设计一个数据库方案，我认为为了安全起见，我应该将 nvarchar 用于我的文本列的数据类型（用于 unicode 支持）。虽然我不希望出现非英文文本，但我认为最好从一开始就支持它以防万一。

我有什么理由坚持使用纯 varchar 吗？性能？

【问题讨论】：

我会将 SQL Server 的版本添加到您的问题中，这可能会有所不同吗？
我目前使用的是 sql server 2005，但我们希望最终能迁移到 2008。

标签： sql sql-server varchar nvarchar

【解决方案1】：

在当今的 i18n 世界中，nvarchar 很有意义。 varchar 可能对指定不是 unicode 的数据有意义（也许您有一些要求为 ASCII 的系统字段）。

我会默认使用 nvarchar 来表示名称、描述、地址等内容。

varchar 更小，因此varchar 可能比nvarchar 节省一些 IO（但请注意，代码页也成为一个更大的问题）。

【讨论】：

【解决方案2】：

另外，请参阅此问题：VARCHAR vs NVARCHAR performance.

就个人而言，我说坚持使用 varchar（正如我在此线程中回答的那样）。存在不小的性能开销。

【讨论】：

【解决方案3】：

我们几乎对所有事情都使用 VARCHAR，而 NVARCHAR 只是非常偶尔。

产品代码不需要 NVarchar - 我们不允许在其中包含 A-Z、0-9 和“_”以外的任何内容...

它是存储空间的两倍，但每个索引页（和每个数据页）只有一半的条目，一半的内存缓存被“浪费”，更多的 CPU 周期来比较数据，等等。

IME 常用的外国口音只能在 Varchar 中找到（即 LATIN-1）。我们没有计划做中文或其他替代字符集，当我们能够通过从第一天开始使用 NVarchar 来处理该字符集时，我们最不担心 - 从右到左或垂直对齐文本？ :(

如果您允许使用 NVarchar 作为名称，您将如何从键盘输入扩展字符？如果您导入数据（因此它已经是 NVarchar），您将如何使用标准 QWERTY 键盘搜索该客户。国际化应用程序涉及很多事情，所以我认为“使用 NVarchar 允许它”是没有意义的。

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

【讨论】：

【解决方案4】：

是的，性能，大小。 nvarchar 占用更多字节，我认为它是双倍的（如果我错了，请纠正我），这是因为 unicode 支持。因此，如果您不需要 unicode 支持，请使用常规 varchar。

【讨论】：

虽然我不确定他们在 SQL SERVER 中使用哪种 unicode 编码，但它可以是可变的。即，在某些编码中，unicode 中的一个字符可以是 1-4 个字节。

【解决方案5】：

如前所述，权衡是面向未来与性能。以我的经验，SQL Server 在 CPU 和内存限制较低的情况下表现相当不错，但它的磁盘 I/O 速度很慢，而且它真的很突兀。

如果您没有双字节字符集（即汉字）的计划，请坚持使用 VARCHAR(MAX)。

【讨论】：

【解决方案6】：

一般来说；从约束最少的最昂贵的数据类型开始。将其投入生产。如果性能开始成为问题，请找出这些 nvarchar 列中实际存储的内容。里面有没有不适合 varchar 的字符？如果没有，请切换到 varchar。在你知道痛苦在哪里之前，不要尝试预先优化。我的猜测是 nvarchar/varchar 之间的选择不会在可预见的未来减慢您的应用程序的速度。在应用程序的其他部分中，性能调整将为您带来更多收益。

【讨论】：