只是nvarchar支持多字节字符吗?如果是这样的话,除了存储问题之外,使用varchars真的有什么意义吗?


当前回答

varchar适用于存储非unicode,这意味着有限的字符。虽然nvarchar是varchar的超集,所以我们可以使用varchar存储哪些字符,但我们可以在不忽略函数的情况下存储更多字符。

有人评论说,现在存储/空间不是问题。即使空间不是一个问题,确定最佳数据类型也应该是一项要求。

这不仅仅是关于存储!“数据移动”,你就知道我要去哪里了!

其他回答

遵循Sql Server VARCHAR和NVARCHAR数据类型之间的差异。在这里,你可以看到一个非常描述性的方式。

一般来说,varchar将数据存储为Unicode,因此,如果要在数据列中存储多语言数据(多种语言),则需要N变量。

nvarchar列可以存储任何Unicode数据。varchar列限制为8位代码页。有些人认为应该使用varchar,因为它占用更少的空间。我认为这不是正确的答案。代码页不兼容性是一个难题,Unicode是解决代码页问题的良方。现在磁盘和内存都很便宜,真的没有理由再浪费时间摆弄代码页了。

所有现代操作系统和开发平台都在内部使用Unicode。通过使用nvarchar而不是varchar,可以避免每次读取或写入数据库时进行编码转换。转换需要时间,而且容易出错。从转换错误中恢复是一个非常重要的问题。

如果您使用的是仅使用ASCII的应用程序,我仍然建议在数据库中使用Unicode。操作系统和数据库排序算法将更好地使用Unicode。Unicode在与其他系统接口时避免了转换问题。你将为未来做准备。您可以始终验证您的数据是否仅限于7位ASCII,无论您要维护的是什么遗留系统,即使您享受完全Unicode存储的一些好处。

与varchar相比,nvarchar使用起来是安全的,因为nvarchar也允许unicode字符,所以我们的代码不会出错(类型不匹配)。当我们在SQL Server查询中使用where条件时,如果我们使用的是=运算符,它会多次抛出错误。可能的原因是我们的映射列将在varchar中定义。如果我们在nvarchar中定义它,这个问题就不会发生。尽管如此,我们还是坚持varchar并避免这个问题,我们最好使用LIKE关键字而不是=。

由于SQL Server 2019 varchar列支持UTF-8编码。

因此,从现在开始,不同的是规模。

在转换为速度差异的数据库系统中。

更少的数据=更少的IO+更少的内存=通常速度更快。阅读上面的文章了解数字。

从现在开始在UTF8中使用varchar!

只有当您拥有2048-16383和16384-65535范围内的大量字符时,您才需要测量

虽然NVARCHAR存储Unicode,但您应该考虑借助于排序,您也可以使用VARCHAR并保存本地语言的数据。

想象一下下面的场景。

DB的排序规则是波斯语,您可以在VARCHAR(10)数据类型中保存一个类似“علی”(阿里的波斯语书写)的值。没有问题,DBMS只使用三个字节来存储它。

但是,如果要将数据传输到另一个数据库并查看正确的结果,则目标数据库必须与目标数据库具有相同的排序规则,在本例中为波斯语。

如果目标排序规则不同,则会在目标数据库中看到一些问号(?)。

最后,请记住,如果您使用的是用于本地语言的大型数据库,我建议您使用位置,而不是使用太多空间。

我相信设计会有所不同。这取决于你工作的环境。