varchar和nvarchar有什么区别？
Answers:
一nvarchar列可以存储任何Unicode数据。甲varchar柱被限制为一个8位的代码页。有人认为varchar应该使用它，因为它占用更少的空间。我相信这不是正确的答案。代码页不兼容是一种痛苦，而Unicode是解决代码页问题的方法。如今，借助廉价的磁盘和内存，确实没有理由再浪费时间浪费代码页了。
所有现代操作系统和开发平台内部都使用Unicode。通过使用nvarchar而不是varchar，您可以避免在每次从数据库读取或写入数据库时进行编码转换。转换需要时间，并且容易出错。从转换错误中恢复并不是一个简单的问题。
如果要与仅使用ASCII的应用程序接口，我仍然建议在数据库中使用Unicode。操作系统和数据库排序算法将与Unicode一起更好地工作。与其他系统连接时，Unicode避免了转换问题。您将为未来做准备。而且，即使享受完整的Unicode存储的某些优势，您也始终可以验证对于必须维护的任何旧版系统，数据都限制为7位ASCII。
varchar：可变长度的非Unicode字符数据。数据库排序规则确定数据使用哪个代码页存储。
nvarchar：可变长度的Unicode字符数据。取决于数据库排序规则进行比较。
掌握了这些知识之后，请使用与您的输入数据相匹配的任何一种（ASCII与Unicode）。
float存入an int并继续进行，“请确保小数点丢失。” 只是不要。
我一直使用nvarchar，因为它允许我构建的所有内容都可以承受我向它抛出的几乎所有数据。我的CMS系统偶然使用了中文，因为我使用了nvarchar。如今，任何新应用程序都不必真正关心所需的空间量。
"never"至少在技术上消除了与使用引号相矛盾的风险。
这取决于如何安装Oracle。在安装过程中，将设置NLS_CHARACTERSET选项。您可以通过查询找到它SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'。
如果您的NLS_CHARACTERSET是Unicode编码（例如UTF8），那就太好了。使用VARCHAR和NVARCHAR几乎相同。现在停止阅读，继续阅读。否则，或者如果您无法控制Oracle字符集，请继续阅读。
VARCHAR —数据以NLS_CHARACTERSET编码存储。如果同一服务器上还有其他数据库实例，则您可能会受到这些实例的限制。反之亦然，因为您必须共享设置。这样的字段可以存储可以使用该字符集进行编码的任何数据，而别无其他。因此，例如，如果字符集为MS-1252，则只能存储英文字母，少数带重音符号的字母以及其他几个字母（如€和-）。您的应用程序仅对少数地区有用，无法在世界上其他任何地方运行。因此，它被认为是一个坏主意。
NVARCHAR —数据以Unicode编码存储。支持每种语言。一个好主意。
那存储空间呢？VARCHAR通常是有效的，因为字符集/编码是针对特定语言环境自定义设计的。NVARCHAR字段以具有讽刺意味的NLS设置为基础，以UTF-8或UTF-16编码存储。UTF-8对于“西方”语言非常有效，同时仍支持亚洲语言。UTF-16对于亚洲语言非常有效，同时仍支持“西方”语言。如果担心存储空间，请选择一个NLS设置以使Oracle适当地使用UTF-8或UTF-16。
处理速度如何？大多数新的编码平台都本机使用Unicode（Java，.NET，甚至几年前的C ++ std :: wstring！），因此，如果数据库字段为VARCHAR，它将迫使Oracle在每次读取或写入时在字符集之间进行转换，效果不是很好。使用NVARCHAR避免了转换。
底线：使用NVARCHAR！它避免了限制和依赖性，适合存储空间，并且通常也最适合性能。
我的两分钱
如果未使用正确的数据类型，则索引可能会失败：
在SQL Server中：当您在VARCHAR列上有一个索引并将其显示为Unicode字符串时，SQL Server不会使用该索引。当您将BigInt呈现给包含SmallInt的索引列时，也会发生同样的事情。即使BigInt小到足以成为SmallInt，SQL Server也无法使用索引。另一种解决方法是不存在此问题（将SmallInt或Ansi-Code提供给已索引的BigInt或NVARCHAR列时）。数据类型在不同的DBMS（数据库管理系统）之间可能会有所不同：
知道每个数据库都有略有不同的数据类型，而VARCHAR并非在每个地方都具有相同的含义。虽然SQL Server具有VARCHAR和NVARCHAR，但是Apache / Derby数据库只有VARCHAR，而VARCHAR是Unicode的。
尽管NVARCHAR存储Unicode，但您应在排序规则的帮助下考虑，也可以使用VARCHAR和保存本地语言的数据。
试想一下以下情况。
您数据库的排序规则是波斯语，您在VARCHAR(10)数据类型中保存了一个类似“علی”（阿里的波斯语写作）的值。没问题，DBMS仅使用三个字节来存储它。
但是，如果要将数据传输到另一个数据库并查看正确的结果，则目标数据库必须与目标（在本示例中为Persian）具有相同的排序规则。
如果目标排序规则不同，则会在目标数据库中看到一些问号（？）。
最后，请记住，如果您正在使用庞大的数据库来使用本地语言，我建议您使用位置而不是使用太多空间。
我相信设计可以有所不同。这取决于您工作的环境。
我看了一下答案，很多人似乎建议使用nvarcharover varchar，因为空间不再是问题，因此启用Unicode进行少量存储不会造成任何危害。好吧，当您想在列上应用索引时，情况并非总是如此。SQL Server可以索引的字段的大小限制为900字节。因此，如果您有一个，varchar(900)您仍然可以为其编制索引，但不能varchar(901)。使用nvarchar，字符数减半，因此您最多可以索引nvarchar(450)。因此，如果您有信心不需要nvarchar，我不建议您使用它。
通常，在数据库中，我建议坚持使用所需的大小，因为您可以随时进行扩展。例如，一个在工作中的同事曾经认为，使用nvarchar(max)色谱柱不会造成任何危害，因为我们完全没有存储问题。稍后，当我们尝试在该列上应用索引时，SQL Server拒绝了此操作。但是，如果他从even开始varchar(5)，那么我们可以稍后将其扩展到所需的范围，而不会出现问题，这将需要我们制定现场迁移计划来解决此问题。
如果使用单个字节存储字符，则有256种可能的组合，因此您可以保存256个不同的字符。排序规则是一种模式，它定义了字符以及对其进行比较和排序的规则。
最常见的是Latin1（ANSI）1252。单字节字符集也不足以存储许多语言使用的所有字符。例如，某些亚洲语言有数千个字符，因此每个字符必须使用两个字节。
Unicode标准
当在网络中使用使用多个代码页的系统时，变得难以管理通信。为了使事情标准化，ISO和Unicode联盟引入了Unicode。Unicode使用两个字节存储每个字符。即可以定义65,536个不同的字符，因此几乎所有字符都可以用Unicode覆盖。如果两台计算机使用Unicode，则每个符号都将以相同的方式表示，并且不需要转换-这是Unicode背后的思想。
SQL Server具有两类字符数据类型：
- 非Unicode（char，varchar和text）
- Unicode（nchar，nvarchar和ntext）
如果我们需要保存来自多个国家的字符数据，请始终使用Unicode。
我必须在这里说（我意识到我可能要对自己敞开心to！），但是可以肯定的是，唯一一次NVARCHAR实际上比所有排序规则都更有用（注意那里的更多！）VARCHAR。依赖系统和数据库本身内部是相同的...？如果不是这样，则无论如何都必须进行归类转换，因此它VARCHAR与一样可行NVARCHAR。
除此之外，某些数据库系统（例如SQL Server（2012年之前））的页面大小大约为1。8K。因此，如果您要存储未存储在诸如a TEXT或NTEXTfield之类的内容中的可搜索数据，则VARCHAR可以提供全部8k的空间，而NVARCHAR仅提供4k（双字节，双倍空间）。
概括地说，我想其中之一的使用取决于：
- 项目或背景
- 基础设施
- 数据库系统
遵循Sql Server VARCHAR和NVARCHAR数据类型之间的区别。在这里您可以以非常描述性的方式看到。
通常，nvarchar将数据存储为Unicode，因此，如果要在数据列中存储多语言数据（一种以上的语言），则需要N变体。
Varchar(n)和之间的主要区别nvarchar(n)是：
Varchar（可变长度，非Unicode字符数据）大小最大为8000。1.这是可变长度数据类型
用于存储非Unicode字符
每个字符占用1个字节的空间
Nvarchar：可变长度Unicode字符数据。
1.这是一个可变长度的数据类型
2.用于存储Unicode字符。
- 数据以Unicode编码存储。支持每种语言。（例如阿拉伯语，德语，印地语等语言）
Jeffrey L Whitledge的信誉得分约为47000，建议使用nvarchar
信誉得分约为33200的所罗门·鲁兹基建议：不要总是使用NVARCHAR。这是非常危险的，而且往往是昂贵的态度/方法。
varchar和nvarchar SQL Server数据类型之间的主要性能差异是什么？
https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4
双方都享有如此高的声誉，学习型sql服务器数据库开发人员会选择什么？
如果您选择不一致，则会在答案和评论中有许多关于性能问题的警告。
有关于性能的pro / con nvarchar注释。
有关于性能的pro / con varchar注释。
我对具有数百列的表有特殊的要求，这本身可能是不寻常的？
我选择varchar以避免接近SQL * server 2012的8060字节表记录大小限制。
对我来说，使用nvarchar超过了8060字节的限制。
我还认为我应该将相关代码表的数据类型与主要中央表的数据类型进行匹配。
我已经看到南澳大利亚州政府在以前的经验丰富的数据库开发人员的工作场所使用varchar列，在该行中，表行数将达到数百万甚至更多（在非常大的情况下，很少有nvarchar列，如果有的话）表），因此预期的数据行量可能会成为此决策的一部分。