varchar 和 nvarchar 有什么区别？

Question

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

Answer 1

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

Varchar （可变长度，非-Unicode字符数据）大小最大为8000。

1. 它是一种变长数据类型
2. 用于存储非Unicode字符
3. 每个字符占用1个字节的空间

Nvarchar：变量-长度 Unicode 字符数据。

1. 它是一种可变长度数据类型，
2. 用于存储Unicode字符。
3. 数据以 Unicode 编码存储。 每一个
   支持语言。 （例如阿拉伯语、德语、印地语等语言）

Answer 2

我的两分钱

1. 如果不使用正确的数据类型，索引可能会失败：
   在 SQL Server 中：当您在 VARCHAR 列上有索引并为其提供 Unicode 字符串时，SQL Server 不会使用该索引。 当您将 Bi​​gInt 呈现给包含 SmallInt 的索引列时，也会发生同样的情况。 即使 BigInt 小到足以成为 SmallInt，SQL Server 也无法使用该索引。 相反，您不会遇到此问题（当向索引 BigInt 或 NVARCHAR 列提供 SmallInt 或 Ansi-Code 时）。

2. 不同 DBMS（数据库管理系统）的数据类型可能有所不同：
   要知道每个数据库的数据类型都略有不同，并且 VARCHAR 并不意味着在所有地方都相同。 虽然 SQL Server 具有 VARCHAR 和 NVARCHAR，但 Apache/Derby 数据库仅具有 VARCHAR，并且 VARCHAR 采用 Unicode。

Answer 3

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

“Unicode”是指 16 位字符编码方案，允许将许多其他语言（如阿拉伯语、希伯来语、中文、日语）的字符编码在单个字符集中。

这意味着 unicodes 每个字符使用 2 个字节来存储，而 nonunicodes 每个字符仅使用一个字节来存储。 这意味着与非 unicode 相比，unicode 需要双倍的存储容量。

Answer 4

你说得对。 nvarchar 存储 Unicode 数据，而 varchar 存储单字节字符数据。 除了您已经提到的存储差异（nvarchar 需要两倍于 varchar 的存储空间）之外，您更喜欢 nvarchar 而不是 的主要原因>varchar 将是国际化（即以其他语言存储字符串）。

Answer 5

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

Answer 6

我想说，这要看情况。

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

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

Answer 7

如果用一个字节来存储一个字符，就有256种可能的组合，从而可以保存256个不同的字符。 排序规则是定义字符以及比较和排序字符的规则的模式。

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

Unicode 标准

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

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

• 非 Unicode（char、varchar 和 text）
• Unicode（nchar、nvarchar 和 ntext）

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

Answer 8

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

一般来说，在数据库中，我建议坚持您需要的大小，因为您始终可以扩展。 例如，工作中的一位同事曾经认为对列使用nvarchar(max)没有什么坏处，因为我们的存储根本没有问题。 后来，当我们尝试对此列应用索引时，SQL Server 拒绝了这一点。 然而，如果他一开始就使用 varchar(5)，我们稍后就可以简单地将其扩展为我们需要的内容，而不会出现需要我们制定现场迁移计划来解决此问题的问题。

Answer 9

虽然 NVARCHAR 存储 Unicode，但您应该考虑通过排序规则的帮助，您也可以使用 VARCHAR 并保存本地语言的数据。

想象一下以下场景。

您的数据库的排序规则是波斯语，您可以在 VARCHAR(10) 数据类型中保存一个值，如 '자대'（Ali 的波斯语书写）。 没有问题，DBMS只用三个字节来存储它。

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

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

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

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

Answer 10

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 列（如果有的话））表），因此预期的数据行量可能成为此决策的一部分。

Answer 11

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

除此之外，某些数据库系统（例如 SQL Server（2012 年之前））具有页面大小约。 8K。 因此，如果您要存储的可搜索数据不是保存在 TEXT 或 NTEXT 字段中，那么 VARCHAR 提供了完整的 8k 值空间，而 NVARCHAR 仅提供 4k（字节数加倍，空间加倍）。

总而言之，我想，两者的使用取决于：

• 项目或上下文
• 基础设施
• 数据库系统

Answer 12

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

一般来说，nvarchar 将数据存储为 Unicode，因此，如果要在数据列中存储多语言数据（不止一种语言），则需要 N 变体。

Answer 13

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

Answer 14

varchar适合存储非unicode，这意味着有限的字符。 而 nvarchar 是 varchar 的超集，因此除了我们可以使用 varchar 存储的字符之外，我们还可以在不忽略函数的情况下存储更多字符。

有人评论说，如今存储/空间不再是问题。 即使空间对一个人来说不是问题，识别最佳数据类型也应该是一个要求。

这不仅仅是存储的问题！ “数据移动”，你就知道我要走向何方了！

Answer 15

与此线程中的一些过时答案相反，varchar 可以存储 Unicode 字符，如果您想使用 UTF-8，这也是一种可行的方法。
解决方案是将数据库排序规则设置为 Latin1_General_100_CI_AS_SC_UTF8

CREATE DATABASE [TestUTF-8] COLLATE Latin1_General_100_CI_AS_SC_UTF8
GO
USE [TestUTF-8]
GO

-- using varchar works
DECLARE @XML xml = '<?xml version="1.0" encoding="utf-8"?>
<test>
    <status>Success ✅</status>
</test>
'

-- using nvarchar will fail (XML parsing: line 1, character 38, unable to switch the encoding)
-- DECLARE @XML xml = N'<?xml version="1.0" encoding="utf-8"?>
-- <test>
--     <status>Success ✅</status>
-- </test>
-- '

SELECT [status] = c.c.value('(./status)[1]', 'varchar(max)') 
FROM @XML.nodes('/test') c(c)

Answer 16

nvarchar 列可以存储任何 Unicode 数据。 varchar 列仅限于 8 位代码页。 有些人认为应该使用varchar，因为它占用的空间更少。 我相信这不是正确的答案。 代码页不兼容是一个痛苦的问题，而 Unicode 是解决代码页问题的良药。 如今，有了便宜的磁盘和内存，真的没有理由再浪费时间在代码页上乱搞了。

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

如果您与仅使用 ASCII 的应用程序交互，我仍然建议在数据库中使用 Unicode。 操作系统和数据库排序算法将更好地与 Unicode 配合使用。 Unicode 避免了与其他系统交互时出现的转换问题。 你将为未来做好准备。 对于您必须维护的任何遗留系统，您始终可以验证您的数据是否仅限于 7 位 ASCII，即使同时享受完整 Unicode 存储的一些好处。

Answer 17

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

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

掌握了这些知识后，就可以使用与您的输入数据匹配的任何一个（ASCII 与 Unicode）。

Answer 18

我总是使用 nvarchar，因为它允许我正在构建的任何内容能够承受我向其抛出的几乎所有数据。 我的CMS系统偶然显示中文，因为我使用了nvarchar。 如今，任何新应用程序都不应该真正关心所需的空间量。

Answer 19

自 SQL Server 以来2019 varchar 列支持 UTF-8 编码。

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

在数据库系统中，这会转化为速度上的差异。

一般来说，更少的数据 = 更少的 IO + 更少的内存 = 更高的速度。 阅读上面的文章了解数字。

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

仅当您拥有 大比例 字符范围为 2048 - 16383 和 16384 - 65535 的数据时 - 您才必须测量

Answer 20

这取决于 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 21

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

Answer 22

varchar 仅用于非 Unicode 字符，而 nvarchar 用于 unicode 和 >非 unicode 字符。 下面给出了它们之间的其他一些区别。

VARCHAR 与 NVARCHAR

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