varchar和nvarchar有什么区别？

Question

只是nvarchar支持多字节字符吗？如果是这种情况，除了存储问题之外，使用varchars

还有什么意义吗？

Answer 1

nvarchar列可以存储任何Unicode数据。 varchar列仅限于8位代码页。有些人认为应该使用varchar，因为它占用的空间更少。我相信这不是正确的答案。代码页不兼容性很痛苦，Unicode可以解决代码页问题。现在有了廉价的磁盘和内存，实际上没有理由浪费时间来处理代码页了。

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

如果您与仅使用ASCII的应用程序连接，我仍然建议在数据库中使用Unicode。操作系统和数据库整理算法将更好地与Unicode一起使用。在与其他系统连接时，Unicode可避免转换问题。你将为未来做准备。您可以随时验证您的数据是否仅限于7位ASCII，以用于您必须维护的任何遗留系统，即使在享受完整Unicode存储的一些优势的同时也是如此。

Answer 2

varchar：可变长度的非Unicode字符数据。数据库排序规则确定使用哪个代码页存储数据。

nvarchar：可变长度的Unicode字符数据。取决于数据库排序规则进行比较。

有了这些知识，请使用与输入数据匹配的任何一种（ASCII v.Unicode）。

Answer 3

我总是使用nvarchar，因为它允许我正在构建的任何数据，以承受我投入的任何数据。我的CMS系统偶然会中文，因为我使用的是nvarchar。如今，任何新应用程序都不应该真正关注所需的空间量。

Answer 4

这取决于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！它避免了限制和依赖性，适用于存储空间，通常也最适合性能。

Answer 5

nvarchar将数据存储为Unicode，因此，如果您要在数据列中存储多语言数据（多种语言），则需要使用N变体。

Answer 6

我的两分钱

1. 不使用正确的数据类型时，索引可能会失败：
   在SQL Server中：当您在VARCHAR列上有索引并为其提供Unicode字符串时，SQL Server不会使用该索引。当您将BigInt呈现给包含SmallInt的索引列时，会发生同样的情况。即使BigInt小到可以成为SmallInt，SQL Server也无法使用索引。另一种方法是没有这个问题（当将SmallInt或Ansi-Code提供给索引的BigInt ot NVARCHAR列时）。

2. 数据类型可能因不同的DBMS（数据库管理系统）而异：
   知道每个数据库的数据类型略有不同，VARCHAR并不代表所有数据类型。虽然SQL Server具有VARCHAR和NVARCHAR，但Apache / Derby数据库只有VARCHAR，而VARCHAR是Unicode。

Answer 7

主要 nvarchar 存储Unicode字符， varchar 存储非Unicode字符。

“Unicodes”是指16位字符编码方案，允许将来自阿拉伯语，希伯来语，中文，日语等许多其他语言的字符编码为单个字符集。

这意味着unicodes每个字符使用2个字节进行存储，非单元只使用每个字符一个字节进行存储。这意味着与非unicode相比，unicodes需要双倍的存储容量。

Answer 8

你是对的。 nvarchar存储Unicode数据，而varchar存储单字节字符数据。除了存储差异（nvarchar需要两倍于[{1}}的存储空间），您已经提到过，优先varchar优于nvarchar的主要原因是国际化（即存储）其他语言的字符串）。

Answer 9

我想说，这取决于。

如果您开发一个桌面应用程序，其中操作系统使用Unicode（与所有当前的Windows系统一样），并且语言本身支持Unicode（默认字符串是Unicode，如Java或C＃），那么请转到nvarchar。

如果你开发一个Web应用程序，其中字符串以UTF-8形式出现，而语言是PHP，它本身仍不支持Unicode（在5.x版本中），那么varchar可能是更好的选择。

Answer 10

nVarchar将帮助您存储Unicode字符。如果您想存储本地化数据，这是可行的方法。

Answer 11

如果使用单个字节存储字符，则有256种可能的组合，因此您可以保存256个不同的字符。整理是一种模式，它定义了字符以及比较和排序的规则。

1252，这是Latin1（ANSI），是最常见的。单字节字符集也不足以存储许多语言使用的所有字符。例如，某些亚洲语言有数千个字符，因此每个字符必须使用两个字节。

Unicode标准

当在网络中使用使用多个代码页的系统时，管理通信变得困难。为了标准化，ISO和Unicode联盟引入了 Unicode 。 Unicode使用两个字节来存储每个字符。即可以定义65,536个不同的字符，因此几乎所有字符都可以用Unicode覆盖。如果两台计算机使用Unicode，则每个符号将以相同的方式表示，不需要转换 - 这就是Unicode背后的想法。

SQL Server有两类字符数据类型：

• 非Unicode（字符，varchar和文本）
• Unicode（nchar，nvarchar和ntext）

如果我们需要保存来自多个国家/地区的角色数据，请始终使用Unicode。

Answer 12

虽然NVARCHAR存储了Unicode，但您应该在排序规则的帮助下考虑使用VARCHAR并保存您当地语言的数据。

想象一下以下情况。

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

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

如果您的目标排序规则不同，您会在目标数据库中看到一些问号（？）。

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

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

Answer 13

我必须在这里说（我意识到我可能会打开自己的平板！），但肯定是NVARCHAR实际上更多有用的唯一时间（注意 more 那里！）而不是VARCHAR当所有依赖系统和数据库本身的所有排序规则相同时......？如果没有，则无论如何都必须进行整理转换，因此VARCHAR与NVARCHAR一样可行。

除此之外，某些数据库系统（例如SQL Server (before 2012)）的页面大小约为。 8K。因此，如果您正在考虑存储未在TEXT或NTEXT字段中保存的可搜索数据，则VARCHAR提供完整的8k空间，而NVARCHAR仅提供4k（字节加倍，空间加倍）。

我想，总而言之，使用任何一种都取决于：

• 项目或背景
• 基础设施
• 数据库系统

Answer 14

我查看了答案，很多人似乎建议使用nvarchar而不是varchar，因为空间不再是问题，所以启用Unicode以获得额外的存储空间没有任何害处。嗯，当你想在列上应用索引时，情况并非总是如此。 SQL Server对您可以索引的字段大小的限制为900字节。因此，如果您有varchar(900)，您仍然可以为其编制索引，但不能varchar(901)。使用nvarchar时，字符数减半，因此您最多可以索引nvarchar(450)。因此，如果您确信不需要nvarchar，我建议您不要使用它。

通常，在数据库中，我建议坚持您需要的大小，因为您可以随时扩展。例如，一位工作的同事曾经认为使用nvarchar(max)列没有任何害处，因为我们对存储没有任何问题。稍后，当我们尝试在此列上应用索引时，SQL Server拒绝了此操作。但是，如果他开始使用varchar(5)，我们可以稍后将其扩展为我们需要的，而不会出现需要我们执行现场迁移计划来解决此问题的问题。

Answer 15

关注 Difference Between Sql Server VARCHAR and NVARCHAR Data Type 。在这里，您可以用非常具有描述性的方式看到。

在generalnvarchar中，数据存储为Unicode，因此，如果要在数据列中存储多语言数据（多种语言），则需要N变量。

Answer 16

Varchar(n)和nvarchar(n)之间的主要区别是：

Varchar（可变长度，非Unicode字符数据）大小最多为8000。  1.它是一个可变长度的数据类型

1. 用于存储非Unicode字符

2. 每个字符占用1个字节的空间



Nvarchar：可变长度的Unicode字符数据。

1.它是一个可变长度的数据类型

2.用于存储Unicode字符。

1. 数据以Unicode编码存储。一切 支持语言。 （例如阿拉伯语，德语，印地语等语言）

Answer 17

test = [expression.match(self.sourceModel().index(source_row, column, source_parent).data()) for expression in liste for liste, column in self._filters.items()] 仅用于 varchar 而另一方面 non-Unicode characters 用于 nvarchar 和 unicode 字符。下面给出了它们之间的一些其他区别。

VARCHAR 与 NVARCHAR 对比

<头>

	VARCHAR	NVARCHAR
字符数据类型	可变长度的非Unicode字符	可变长度，Unicode 和非 Unicode 字符，如日文、韩文和中文。
最大长度	最多non-unicode	最多8,000 characters
字符大小	每个字符占用4,000 characters	每个 Unicode/非 Unicode 字符占用 1 byte
存储大小	实际长度（以字节为单位）	2 倍实际长度（以字节为单位）
用法	当数据长度可变或可变长度列并且实际数据总是远小于容量时使用	仅用于存储，仅在需要 Unicode 支持（例如日语汉字或韩语韩文字符）时使用。

Answer 18

Since SQL Server 2019 varchar columns support UTF-8 encoding.

因此，从现在开始，区别就是大小。

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

更少的大小=更少的IO +更少的内存=通常可以提高速度。阅读上面的文章以获取数字。

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

仅当您有很大百分比的字符在2048-16383和16384 – 65535范围内的字符时，才需要测量

Answer 19

Jeffrey L Whitledge的信誉评分约为47000，建议使用nvarchar

信誉得分约为33200的所罗门·鲁兹基建议：不要总是使用NVARCHAR。这是非常危险的，而且往往是昂贵的态度/方法。

What are the main performance differences between varchar and nvarchar SQL Server data types?

https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4

这两个声誉很高的人，学习SQL Server数据库开发人员会选择什么？

如果您在选择方面不一致，则会在答案和评论中有很多关于性能问题的警告。

有关于性能的pro / con nvarchar注释。

有关于性能的pro / con varchar评论。

我对具有数百列的表有特殊要求，这本身可能是不寻常的？

我选择varchar以避免接近SQL * server 2012的8060字节表记录大小限制。

对我来说，使用nvarchar超过了8060个字节的限制。

我还认为我应该将相关代码表的数据类型与主要中央表的数据类型进行匹配。

我已经看到南澳大利亚州政府在此工作场所使用过varchar列，这是由以前经验丰富的数据库开发人员所完成的，其中表行数将达到数百万甚至更多（而nvarchar列中只有很少的列）这些非常大的表格），因此也许预期的数据行量将成为此决策的一部分。

Answer 20

与nvarchar相比，

varchar可以安全使用，以使我们的代码无错误（类型不匹配），因为nvarchar也允许使用unicode字符。 当我们在SQL Server查询中使用where条件时，如果我们使用=运算符，它将会抛出错误一些时间。可能的原因是我们的映射列将在varchar中有所不同。如果我们在nvarchar中定义了这个问题，我就不会发生这种情况。我们仍然坚持varchar并避免此问题，我们最好使用LIKE关键字而不是=。