在SQL Server中修改列varchar(255) nvarchar

Question

我正在使用SQL Server 2008 Express，其中一些列被定义为varchar(255)。我应该将这些列转换为NvarChar(255)还是nvarchar(max)？

我之所以问这个问题是因为我读到，对于Unicode字符，nvarchar(255)实际上只会存储1/2的字符数（因为Unicode字符占用2个字节），而使用varchar(255)可以允许我存储255个字符（或者是255-2的偏移量）。

使用nvarchar(max)会有任何性能损失吗？

JDs

- JD.

Answer 1

并不完全如此 - 将数据类型转换为NVarChar（255）并不能将存储的字符数减半 - 它仍然存储了255个字符。它只需要两倍的空间（510字节比255字节）。

您应该转换为NVARCHAR - 即使它始终使用两倍的空间 - 如果您：

• 需要支持阿拉伯语，希伯来语，西里尔文或任何东亚语言 - 只有在Unicode中，您才能实际捕获这些字符
• 需要支持其他使用“标准”拉丁字母表但具有特殊字符的语言 - 像东欧（斯拉夫）语言，具有像 č ă ě 这样的字符 - 这些将存储为varchar()字段中的c, a, e

NVarchar(max)是一个很好的选择 - 如果您真的需要多达2 GB的文本。只是为了“一致”，让所有字符串字段都变成nvarchar(max)是一个非常糟糕的想法 - 您将面临巨大的性能问题。请参见Remus Rusanu关于此主题的文章

- marc_s

Answer 2

每个使用的数据类型都应该有一些合理的理由。

在SQL Server中，nvarchar（255）存储255个Unicode字符（在510字节加开销的情况下）。

当然，可以在varchar列中存储普通的UTF-8编码的Unicode数据 - 源中每个字节对应一个varchar字符（UTF-8会适当地使用多个字节来表示宽字符）。在这种情况下，普通的ASCII数据仅使用每个字符1个字节，因此您不必承担双字节开销。但是，它有很多缺点，其中最大的缺点之一是由于数据可能被编码，因此数据库无法像以前那样协助处理排序和其他字符操作工作。但是，正如我所说的，这是可能的。

我建议对于像帐户号码、许可证号码、带有字母的发票号码、邮政编码、电话号码等这些需要零填充的列，使用适当长度的char或varchar字符。这些是永远不包含任何宽字符的列类型，并且通常仅限于罗马字母和数字，有时甚至没有标点符号，并且通常具有很强的索引。在表格和索引以及数据库引擎的工作集中，所有这些字符的列都不需要额外的NUL高字节的开销。

我建议对于像名称和地址等可能包含宽字符的内容，即使在不可预见的近期内也没有使用，也应使用nvarchar。

我通常从不使用nchar - 我从未需要过需要宽字符的短代码（通常是我选择char列的地方）。

在所有情况下，长度（或最大值）的使用确实应该经过充分的思考。我绝对不会在名称或地址中使用max，并且在基准测试中，开销非常明显。我曾看到将其转换为varchar（length）在查询的中间阶段显着提高了性能。

- Cade Roux