SQL Server - 对 VARCHAR 和 NVARCHAR 的数据库影响 [关闭]答案

【问题标题】：SQL Server - DB Impact on VARCHAR and NVARCHAR [closed]SQL Server - 对 VARCHAR 和 NVARCHAR 的数据库影响 [关闭]
【发布时间】：2017-11-08 23:41:28
【问题描述】：

SQL Server 为开发人员提供了超级简单的选项来创建 VARCHAR 和 NVARCHAR 列。但是，我看到对于存储在列中的相同数据，SQL Server 数据库大小几乎翻了一番。

当然有点夸张，但数据库的大小确实很高。我确实查看了 SQL Server MDB 大小，还检查了带有 VARCHAR 列的表大小和带有 NVARCHAR 列的同一张表。

这是否意味着我们需要明智地使用 NVARCHAR？

【问题讨论】：

现在是 2017 年。您要为每 MB 磁盘空间支付多少费用？
您需要明智地使用所有列类型。 NVARCHAR 是 VARCHAR 大小的 2 倍，因为这是字面上的定义。 Varchar 使用 1 个字节，nvarchar 使用 2（用于更大的 unicode 数据）dba.stackexchange.com/questions/36081/… 你需要存储 unicode 数据吗？如果不是，那么明智地选择 varchar。
如果您不使用 unicode，则没有理由使用 NVARCHAR。
Does that mean that we need to use NVARCHAR sensibly? 是的，总是。像任何类型一样，使用最适合业务用途的类型。否则只会有 4 或 5 种类型，因为为什么还要麻烦呢？您选择的内容和列的大小取决于您要存储的内容。存储名字？我推荐 nvarchar(500) 因为名称可能包含 unicode 字符（500 有待讨论）。存储美国州代码？然后使用 char(2)，因为这是一个已定义且已知的列表，它永远不会包含 unicode 字符并且长度始终为 2。
@JacobH 这不是定义。 N 表示 Unicode。 .NET 使用 Unicode。所有网站也是如此。除非您想处理转换错误，否则使用 varchar 是没有意义的。此外，SQL Server 2016 甚至在 LocalDB 中也提供压缩

标签： sql-server varchar sql-server-2016 nvarchar

【解决方案1】：

这取决于您的要求。

如果您需要存储 unicode，那么您必须使用 NVARCHAR。如果您只存储 ascii 或只存储一种可以以 8 位存储的语言，那么您可以使用 NVARCHAR。如果占用“太多”空间，请使用 VARCHAR。

【讨论】：

即使使用一种语言也可能有多个代码页。不管代码页是什么，当 client 应用程序使用错误的代码页/排序规则存储数据时，使用 varchar 可能会导致转换错误。存储不是问题 - 大小差异不是那么重要，即使在数据仓库中也是如此。自 SQL Server 2016 SP1 起，所有 SQL Server 版本都提供表压缩功能。
尝试存储来自乌克兰或波兰啤酒厂的啤酒瓶销售数据（真实示例）。至少有 3 个排序规则/代码页（德语、乌克兰语、波兰语）。不要介意某些数据可能来自 DB2 或大型机。或者尝试使用带有 Latin1 的德语排序规则加入表。即使你有索引，你也会得到一个全表扫描
我没有看到将一种语言存储到具有正确排序规则集的每字符 8 位 (varchar) 中的问题。我从来没有谈论过混合语言。在这种情况下你是对的，它会以一团糟的方式结束。
问题是您必须在 everywhere 中强制执行代码页 - 在数据库、客户端、导入作业和源代码中（以避免错位的文字）。甚至 Windows 1252 本身也不是 ANSI。 “聪明”的引号和撇号可能会被破坏。