varchar和nvarchar有什么区别？

18 回答

• 9

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

  回复于 2024-04-28T15:07:23+08:00
• 1479

  我的两分钱

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

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

  回复于 2024-04-28T15:07:23+08:00
• 4

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

  Varchar （可变长度，非Unicode字符数据）大小高达8000. 1.它是一个可变长度数据类型

  • 用于存储非Unicode字符

  • 占用每个字符1个字节的空间

  

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

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

  2.用于存储Unicode字符 .

  • 数据以Unicode编码存储 . 支持每种语言 . （例如阿拉伯语，德语，印地语等语言等）

  回复于 2024-04-28T15:07:23+08:00
• 5

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

  想象一下以下场景 .

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

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

  如果目标归类不同，则会在目标数据库中看到一些问号（？） .

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

  我相信设计可能会有所不同 . 这取决于您所处理的环境 .

  回复于 2024-04-28T15:07:23+08:00
• 6

  我会说，这取决于 .

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

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

  回复于 2024-04-28T15:07:23+08:00
• 6

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

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

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

  回复于 2024-04-28T15:07:23+08:00
• 4

  主要是 nvarchar 存储Unicode字符和 varchar 存储非Unicode字符 .

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

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

  回复于 2024-04-28T15:07:23+08:00
• 62

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

  回复于 2024-04-28T15:07:23+08:00
• 41

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

  回复于 2024-04-28T15:07:23+08:00
• 16

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

  回复于 2024-04-28T15:07:23+08:00
• 13

  这取决于Oracle的安装方式 . 在安装过程中，将设置NLS_CHARACTERSET选项 . 您可以使用查询 SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET' 找到它 .

  如果你的NLS_CHARACTERSET是像UTF8这样的Unicode编码，那很好 . 使用VARCHAR和NVARCHAR几乎完全相同 . 现在停止阅读，就去吧 . 否则，或者如果您无法控制Oracle字符集，请继续阅读 .

  VARCHAR - 数据存储在NLS_CHARACTERSET编码中 . 如果同一服务器上有其他数据库实例，则可能受其限制;反之亦然，因为你必须分享设置 . Such a field can store any data that can be encoded using that character set, and nothing else . 因此，例如，如果字符集是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！它避免了限制和依赖性，适用于存储空间，通常也是性能最佳的 .

  回复于 2024-04-28T15:07:23+08:00
• 11

  关注Difference Between Sql Server VARCHAR and NVARCHAR Data Type . 在这里你可以用一种非常描述的方式看到 .

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

  回复于 2024-04-28T15:07:23+08:00
• 8

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

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

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

  回复于 2024-04-28T15:07:23+08:00
• 6

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

  回复于 2024-04-28T15:07:23+08:00
• 5

  我不得不在这里说（我意识到我可能会打开自己的一个东西！），但肯定是 NVARCHAR 实际上更有用的唯一时间（注意更多！）比 VARCHAR 是所有整理的时候所有依赖系统和数据库本身都是一样的......？如果没有，那么无论如何都必须进行整理转换，因此 VARCHAR 与 NVARCHAR 一样可行 .

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

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

  • 项目或背景

  • 基础设施

  • 数据库系统

  回复于 2024-04-28T15:07:23+08:00
• 232

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

  一般来说，在数据库中，我建议坚持你需要的大小，因为你总是可以扩展 . 例如，一位工作的同事曾经认为使用 nvarchar(max) 作为列是没有害处的，因为我们对存储没有任何问题 . 稍后，当我们尝试在此列上应用索引时，SQL Server拒绝了此操作 . 然而，如果他开始甚至 varchar(5) ，我们可以简单地将其扩展到我们需要的东西而没有这样的问题，这将需要我们做一个现场迁移计划来解决这个问题 .

  回复于 2024-04-28T15:07:23+08:00
• 29

  在这里您可以看到 varchar 和 nvarchar 之间的差异 .

  

  

  

  

  Reference: SqlHints.com

  有关Nvarchar和varchar的更多信息，请参阅this blog post .

  回复于 2024-04-28T15:07:23+08:00
• 0

  如果使用单个字节存储字符，则有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 .

  回复于 2024-04-28T15:07:23+08:00