varchar 和 nvarchar 有什么区别?
-
02-07-2019 - |
题
难道只是这样吗 nvarchar
支持多字节字符吗?如果是这样的话,除了存储问题之外,使用真的有什么意义吗? varchars
?
解决方案
一个 nvarchar
列可以存储任何 Unicode 数据。A varchar
列仅限于 8 位代码页。有些人认为 varchar
应该使用,因为它占用的空间较小。我相信这不是正确的答案。代码页不兼容是一个痛苦的问题,而 Unicode 是解决代码页问题的良方。如今,有了便宜的磁盘和内存,真的没有理由再浪费时间在代码页上乱搞了。
所有现代操作系统和开发平台都在内部使用 Unicode。通过使用 nvarchar
而不是 varchar
, ,您可以避免每次读取或写入数据库时都进行编码转换。转换需要时间,并且容易出错。从转换错误中恢复是一个不小的问题。
如果您与仅使用 ASCII 的应用程序交互,我仍然建议在数据库中使用 Unicode。操作系统和数据库排序算法将更好地与 Unicode 配合使用。Unicode 避免了接口时的转换问题 其他 系统。你将为未来做好准备。对于您必须维护的任何遗留系统,您始终可以验证您的数据是否仅限于 7 位 ASCII,即使同时享受完整 Unicode 存储的一些好处。
其他提示
我总是使用 nvarchar,因为它允许我正在构建的任何内容能够承受我向其抛出的几乎所有数据。我的CMS系统偶然显示中文,因为我使用了nvarchar。如今,任何新应用程序都不应该真正关心所需的空间量。
这取决于 Oracle 的安装方式。在安装过程中,会设置 NLS_CHARACTERSET 选项。您也许可以通过查询找到它 SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'
.
如果您的 NLS_CHARACTERSET 是 UTF8 等 Unicode 编码,那就太好了。使用 VARCHAR 和 NVARCHAR 几乎相同。现在停止阅读,直接去读吧。否则,或者如果您无法控制 Oracle 字符集,请继续阅读。
VARCHAR — 数据以 NLS_CHARACTERSET 编码存储。如果同一服务器上还有其他数据库实例,您可能会受到它们的限制;反之亦然,因为您必须共享设置。 这样的字段可以存储可以使用该字符集编码的任何数据,而不能存储其他任何数据. 。例如,如果字符集是 MS-1252,则只能存储英文字母、少数重音字母和其他一些字符(例如 € 和 —)。您的应用程序仅对少数区域有用,无法在世界其他任何地方运行。因此,这被认为是一个坏主意。
NVARCHAR — 数据以 Unicode 编码存储。支持每种语言。一个好主意。
存储空间怎么样?VARCHAR 通常是高效的,因为字符集/编码是针对特定区域设置定制设计的。讽刺的是,NVARCHAR 字段以 UTF-8 或 UTF-16 编码存储,基于 NLS 设置。UTF-8 对于“西方”语言非常有效,同时仍然支持亚洲语言。UTF-16 对于亚洲语言非常有效,同时仍然支持“西方”语言。如果担心存储空间,请选择 NLS 设置以使 Oracle 根据需要使用 UTF-8 或 UTF-16。
处理速度怎么样?大多数新的编码平台本身就使用 Unicode(Java、.NET,甚至几年前的 C++ std::wstring!),因此如果数据库字段是 VARCHAR,它会强制 Oracle 在每次读取或写入时在字符集之间进行转换,这不太好。使用 NVARCHAR 可以避免转换。
底线:使用 NVARCHAR!它避免了限制和依赖性,非常适合存储空间,而且通常也最适合性能。
nvarchar 将数据存储为 Unicode,因此,如果要在数据列中存储多语言数据(不止一种语言),则需要 N 变体。
我的两分钱
如果不使用正确的数据类型,索引可能会失败:
在 SQL Server 中:当您在 VARCHAR 列上有索引并为其提供 Unicode 字符串时,SQL Server 不会使用该索引。当您将 BigInt 呈现给包含 SmallInt 的索引列时,也会发生同样的情况。即使 BigInt 小到足以成为 SmallInt,SQL Server 也无法使用索引。相反,您不会遇到此问题(当向索引 BigInt 或 NVARCHAR 列提供 SmallInt 或 Ansi-Code 时)。不同 DBMS(数据库管理系统)之间的数据类型可能有所不同:
要知道,每个数据库的数据类型都略有不同,并且 VARCHAR 并不意味着在所有地方都相同。虽然 SQL Server 具有 VARCHAR 和 NVARCHAR,但 Apache/Derby 数据库仅具有 VARCHAR,并且 VARCHAR 采用 Unicode。
主要是 nvarchar 存储 Unicode 字符和 varchar 存储非 Unicode 字符。
“Unicode”是指 16 位字符编码方案,允许将许多其他语言(如阿拉伯语、希伯来语、中文、日语)的字符编码在单个字符集中。
这意味着 unicodes 每个字符使用 2 个字节来存储,而 nonunicodes 每个字符仅使用一个字节来存储。这意味着与非 unicode 相比,unicode 需要双倍的存储容量。
你说得对。 nvarchar
存储 Unicode 数据,同时 varchar
存储单字节字符数据。除了存储差异之外(nvarchar
需要两倍的存储空间 varchar
),您已经提到过,这是首选的主要原因 nvarchar
超过 varchar
将是国际化(即以其他语言存储字符串)。
我想说,这要看情况。
如果您开发一个桌面应用程序,其中操作系统以 Unicode 运行(就像所有当前的 Windows 系统一样)并且语言本身支持 Unicode(默认字符串是 Unicode,就像 Java 或 C# 中的那样),那么请使用 nvarchar。
如果您开发一个 Web 应用程序,其中字符串采用 UTF-8,语言为 PHP,而 PHP 本身仍然不支持 Unicode(在版本 5.x 中),那么 varchar 可能是更好的选择。
nVarchar 将帮助您存储 Unicode 字符。如果您想存储本地化数据,这是一种可行的方法。
如果用一个字节来存储一个字符,就有256种可能的组合,从而可以保存256个不同的字符。排序规则是定义字符以及比较和排序字符的规则的模式。
1252,即 Latin1 (ANSI),是最常见的。单字节字符集也不足以存储许多语言使用的所有字符。例如,某些亚洲语言有数千个字符,因此每个字符必须使用两个字节。
统一码标准
当在网络中使用使用多个代码页的系统时,管理通信变得困难。为了标准化,ISO 和 Unicode 联盟引入了 统一码. 。Unicode 使用两个字节来存储每个字符。即可以定义65,536个不同的字符,因此Unicode几乎可以覆盖所有字符。如果两台计算机使用 Unicode,则每个符号都将以相同的方式表示,并且不需要转换 - 这就是 Unicode 背后的想法。
SQL Server 有两类字符数据类型:
- 非 Unicode(char、varchar 和 text)
- Unicode(nchar、nvarchar 和 ntext)
如果我们需要保存来自多个国家/地区的字符数据,请始终使用 Unicode。
虽然 NVARCHAR
存储 Unicode,您应该考虑通过排序规则也可以使用 VARCHAR
并保存您的本地语言数据。
想象一下以下场景。
您的数据库的排序规则是波斯语,并且您在 VARCHAR(10)
数据类型。没有问题,DBMS只用三个字节来存储它。
但是,如果您想将数据传输到另一个数据库并查看正确的结果,您的目标数据库必须具有与目标相同的排序规则,在本示例中为波斯语。
如果您的目标排序规则不同,您会在目标数据库中看到一些问号(?)。
最后,请记住,如果您使用的是用于本地语言的大型数据库,我建议使用位置而不是使用太多空格。
我相信设计可以有所不同。这取决于您的工作环境。
我必须在这里说(我意识到我可能会敞开心扉接受批评!),但肯定是唯一一次 NVARCHAR
实际上是 更多的 有用(注意 更多的 在那里!)比 VARCHAR
当所有依赖系统上和数据库本身内的所有排序规则都相同时......?如果不是,那么排序规则转换无论如何都必须发生,所以使得 VARCHAR
就像一样可行 NVARCHAR
.
除此之外,一些数据库系统,例如 SQL Server(2012 年之前) 页面大小约为。8K。因此,如果您正在考虑存储可搜索数据而不是保存在类似 TEXT
或者 NTEXT
那么场 VARCHAR
提供完整 8k 的空间,而 NVARCHAR
仅提供 4k(双倍字节,双倍空间)。
总而言之,我想,两者的使用取决于:
- 项目或背景
- 基础设施
- 数据库系统
跟随 Sql Server VARCHAR 和 NVARCHAR 数据类型之间的区别. 。在这里你可以看到一个非常描述性的方式。
一般来说,nvarchar 将数据存储为 Unicode,因此,如果要在数据列中存储多语言数据(不止一种语言),则需要 N 变体。
我查看了答案,很多人似乎建议使用 nvarchar
超过 varchar
, ,因为空间不再是问题,所以启用 Unicode 来获得少量额外存储也没有坏处。嗯,当您想在列上应用索引时,情况并不总是如此。SQL Server 对可以索引的字段大小有 900 字节的限制。所以如果你有一个 varchar(900)
你仍然可以索引它,但不能 varchar(901)
. 。和 nvarchar
, ,字符数减半,因此您可以索引最多 nvarchar(450)
. 。所以如果你有信心你不需要 nvarchar
, ,我不建议使用它。
一般来说,在数据库中,我建议坚持您需要的大小,因为您始终可以扩展。例如,工作中的一位同事曾经认为使用没有什么坏处 nvarchar(max)
对于一个列,因为我们在存储方面完全没有问题。后来,当我们尝试对此列应用索引时,SQL Server 拒绝了这一点。然而,如果他一开始就连 varchar(5)
, ,我们可以稍后将其扩展为我们需要的内容,而不会出现这样的问题,这将需要我们制定现场迁移计划来解决此问题。
Jeffrey L Whitledge 的声誉评分约为 47000,建议使用 nvarchar
Solomon Rutzky 的声誉评分约为 33200 推荐:不要总是使用 NVARCHAR。这是一种非常危险且往往代价高昂的态度/方法。
varchar 和 nvarchar SQL Server 数据类型之间的主要性能差异是什么?
https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4
两个人的名气都这么高,一个学习sql server数据库开发人员该选择什么?
如果您的选择不一致,答案和评论中会有很多关于性能问题的警告。
对于 nvarchar 的性能,有赞成/反对的评论。
对于性能,有赞成/反对 varchar 的评论。
我对包含数百列的表有一个特殊要求,这本身可能很不寻常?
我选择 varchar 是为了避免接近 SQL*server 2012 的 8060 字节表记录大小限制。
对我来说,使用 nvarchar 超出了 8060 字节的限制。
我还认为我应该将相关代码表的数据类型与主中心表的数据类型相匹配。
我见过以前经验丰富的数据库开发人员在南澳大利亚政府这个工作场所使用 varchar 列,其中表行数将达到数百万或更多(并且在这些非常大的数据库中,很少有 nvarchar 列(如果有的话))表),因此预期的数据行量可能成为此决策的一部分。
nvarchar
与相比使用安全 varchar
为了使我们的代码没有错误(类型不匹配),因为 nvarchar
也允许使用 unicode 字符。当我们使用 where
SQL Server 查询中的条件以及我们是否使用 =
运算符,有时会抛出错误。可能的原因是我们的映射列将定义在 varchar
. 。如果我们将其定义为 nvarchar
这个问题我不会发生。我们依然坚持 varchar
并避免这个问题,我们最好使用 LIKE
关键词而不是 =
.