varchar和nvarchar有什么区别？
这只是nvarchar支持多字节字符？ 如果是这样的话，除了存储问题之外，真的有什么意义可以使用varchars吗？
一个nvarchar列可以存储任何Unicode数据。 一个varchar列被限制在一个8位的代码页中。 有些人认为应该使用varchar因为它占用的空间较less。 我相信这不是正确的答案。 代码页不兼容性是一个痛苦，Unicode是代码页问题的解决scheme。 现在廉价的磁盘和内存，真的没有理由浪费时间在代码页上了。
所有现代操作系统和开发平台都在内部使用Unicode。 通过使用nvarchar而不是varchar ，可以避免每次读取或写入数据库时都进行编码转换。 转换需要时间，并且容易出错。 从转换错误恢复是一个不平凡的问题。
如果您正在使用仅使用ASCII的应用程序接口，我仍然build议在数据库中使用Unicode。 操作系统和数据库整理algorithm将使用Unicode更好地工作。 Unicode与其他系统连接时避免了转换问题。 而你将为未来做准备。 而且，即使在享受完整Unicode存储的某些好处的情况下，您也可以随时validation您的数据是否限于7位ASCII码，无论您需要维护哪个旧版系统。
varchar ：可变长度的非Unicode字符数据。 数据库归类确定数据使用哪个代码页存储。
nvarchar ：可变长度的Unicode字符数据。 取决于数据库sorting规则以进行比较。
有了这些知识，使用与你的input数据相匹配的任何一个（ASCII与Unicode）。
我总是使用nvarchar，因为它允许我正在构build的任何数据，以承受我所扔的任何数据。 我的CMS系统不小心做了中文，因为我用了nvarchar。 现在，任何新的申请都不应该真正关心所需的空间。
在这里你可以看到varchar和nvarchar的区别。
参考： SqlHints.com
有关Nvarchar和varchar的更多信息，请参阅此博客文章 。
这取决于如何安装Oracle。 在安装过程中，设置了NLS_CHARACTERSET选项。 您可能能够通过查询SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'查找SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET' 。
如果你的NLS_CHARACTERSET是一个像UTF8这样的Unicode编码，那么很好。 使用VARCHAR和NVARCHAR非常相似。 现在停止阅读，只是为了它。 否则，或者如果您无法控制Oracle字符集，请继续阅读。
VARCHAR – 数据存储在NLS_CHARACTERSET编码中。 如果在同一台服务器上有其他数据库实例，则可能会受到这些实例的限制; 反之亦然，因为你必须分享这个设置。 这样的字段可以存储任何可以使用该字符集进行编码的数据，而不是其他的 。 例如，如果字符集是MS-1252，则只能存储英文字母，less量重音字母以及其他一些字符（如€和 – ）。 你的应用程序只对几个地区有用，无法在世界其他任何地方操作。 出于这个原因，这被认为是一个坏主意。
NVARCHAR – 数据以Unicode编码存储。 每种语言都支持。 一个好主意。
存储空间呢？ VARCHAR通常是有效的，因为字符集/编码是为特定语言环境定制devise的。 具有讽刺意味的是，NVARCHAR字段以UTF-8或UTF-16编码存储，基于NLS设置。 UTF-8对于“西方”语言非常有效，同时还支持亚洲语言。 对于亚洲语言，UTF-16非常有效，同时还支持“西方”语言。 如果担心存储空间，请selectNLS设置，以使Oracle根据需要使用UTF-8或UTF-16。
处理速度怎么样？ 大多数新的编码平台在本地使用Unicode（Java，.NET，甚至是从几年前的C ++ std :: wstring！），所以如果数据库字段是VARCHAR，它会强制Oracle在每次读取或写入时在字符集之间进行转换，而不是那么好。 使用NVARCHAR可以避免转换。
底线：使用NVARCHAR！ 它避免了限制和依赖性，对于存储空间是很好的，而且通常对性能也是最好的。
nvarchar将数据存储为Unicode，因此，如果要在数据列中存储多语言数据（多种语言），则需要N变体。
我的两分钱
-
如果不使用正确的数据types，索引可能会失败：
在SQL Server中：当您有一个索引在VARCHAR列上并将其显示为Unicodestring时，SQL Server将不使用索引。 将BigInt呈现给包含SmallInt的索引列时，也会发生同样的情况。 即使BigInt小到可以成为SmallInt，SQL Server也不能使用该索引。 另一种方法是没有这个问题（当SmallInt或Ansi-Code提供给索引BigInt或NVARCHAR列时）。 -
数据types可以在不同的DBMS（数据库pipe理系统）之间有所不同：
要知道每个数据库都有略微不同的数据types，VARCHAR并不意味着每个地方都一样。 虽然SQL Server具有VARCHAR和NVARCHAR，但Apache / Derby数据库仅具有VARCHAR，而VARCHAR具有Unicode。
主要是nvarchar存储Unicode字符， varchar存储非Unicode字符。
“Unicodes”意思是16位字符编码scheme，允许来自诸如阿拉伯文，希伯来文，中文，日文等许多其他语言的字符被编码成单个字符集。
这意味着unicodes每个字符使用2个字节来存储，而nonunicodes每个字符只使用一个字节来存储。 这意味着unicodes与non-unicodes相比，需要双倍的存储容量。
你是对的。 nvarchar存储Unicode数据，而varchar存储单字节字符数据。 除了存储差异（ nvarchar需要两倍的存储空间作为varchar ），你已经提到过，selectnvarchar over varchar主要原因是国际化（即以其他语言存储string）。
我会说，这取决于。
如果你开发一个桌面应用程序，其中操作系统工作在Unicode（像所有当前的Windows系统）和语言本身支持Unicode（默认string是Unicode，如在Java或C＃），然后去nvarchar。
如果开发一个Web应用程序，其中string以UTF-8forms出现，并且语言是PHP，但仍然不支持Unicode（在版本5.x中），那么varchar可能是更好的select。
如果使用单个字节来存储字符，则有256种可能的组合，因此可以保存256个不同的字符。 整理是定义字符和规则进行比较和sorting的模式。
1252，这是Latin1（ANSI），是最常见的。 单字节字符集也不足以存储多种语言使用的所有字符。 例如，一些亚洲语言有数千个字符，所以他们必须使用每个字符两个字节。
Unicode标准
当在networking中使用使用多个代码页的系统时，pipe理通信变得困难。 为了标准化，ISO和Unicode联盟引入了Unicode 。 Unicode使用两个字节来存储每个字符。 那就是65536个不同的字符可以定义，所以几乎所有的字符都可以用Unicode覆盖。 如果两台计算机使用Unicode，则每个符号将以相同的方式表示，不需要转换 – 这是Unicode背后的想法。
SQL Server有两类字符数据types：
- 非Unicode（char，varchar和文本）
- Unicode（nchar，nvarchar和ntext）
如果我们需要保存来自多个国家的字符数据，请始终使用Unicode。
nVarchar将帮助您存储Unicode字符。 如果你想存储本地化的数据，这是一条路。
遵循Sql Server VARCHAR和NVARCHAR数据types的区别 。 在这里你可以看到一个非常描述性的方式。
一般而言，nvarchar将数据存储为Unicode，因此，如果要在数据列中存储多语言数据（多种语言），则需要N变体。
我必须在这里说（我意识到，我可能会打开自己的slating！），但当然NVARCHAR实际上是唯一的时间实际上比VARCHAR 更有用（注意更多 ！）是所有的sorting规则在所有的依赖系统和数据库本身是一样的…？ 如果不是的话，整理转换必须发生，所以VARCHAR就像NVARCHAR一样可行。
为此，一些数据库系统（如2012年以前的SQL Server）的页面大小约为。 8K。 因此，如果您正在寻找存储不在TEXT或NTEXT字段中的可search数据，则VARCHAR提供完整的8k空间值，而NVARCHAR只能提供4k（双倍的字节空间）。
我想，总而言之，两者的使用都依赖于：
- 项目或上下文
- 基础设施
- 数据库系统
我看了一下答案，许多人似乎build议使用nvarchar over varchar ，因为空间已经不再是问题了，所以启用Unicode只需要额外的less量存储就没有任何坏处。 那么，当你想在你的列上应用一个索引时，情况并不总是这样。 SQL Server在您可以索引的字段的大小上有900个字节的限制。 所以，如果你有一个varchar(900)你仍然可以索引它，但不是varchar(901) 。 用nvarchar ，字符数减半，所以你可以索引到nvarchar(450) 。 所以，如果你有信心，你不需要nvarchar ，我不build议使用它。
一般来说，在数据库中，我build议坚持你需要的大小，因为你总是可以扩展。 例如，一位同事在工作中曾经认为对列使用nvarchar(max)没有任何坏处，因为我们根本没有存储问题。 之后，当我们试图在这个列上应用一个索引时，SQL Server拒绝了这个。 但是，如果他开始使用varchar(5) ，我们可以简单地将它扩展到我们所需要的，而没有这样的问题，需要我们做一个现场迁移计划来解决这个问题。
Varchar(n)和nvarchar(n)的主要区别是： 
Varchar （可变长度，非Unicode字符数据）大小高达8000. 1.是一种可变长度的数据types
-
用于存储非Unicode字符
-
每个字符占用1个字节的空间
Nvarchar ：可变长度的Unicode字符数据。
1.这是一个可变长度的数据types
2.用于存储Unicode字符。
- 数据以Unicode编码存储。 每种语言都支持。 （例如阿拉伯语，德语，印地语等等）
尽pipeNVARCHAR存储Unicode，但您应该在sorting规则的帮助下考虑使用VARCHAR并保存您的本地语言的数据。
试想下面的情况。
您的数据库的sorting规则是波斯文，并在VARCHAR(10)数据types中保存“علی”（阿里的波斯语书写VARCHAR(10) 。 没有问题，DBMS只使用三个字节来存储它。
但是，如果要将数据传输到另一个数据库并查看正确的结果，则在本示例中，目标数据库必须与波斯语的目标具有相同的sorting规则。
如果您的目标sorting规则不同，则会在目标数据库中看到一些问号（？）。
最后，请记住，如果您正在使用一个庞大的数据库来使用您的本地语言，我build议使用位置而不是使用太多的空间。
我相信devise可能会有所不同。 这取决于你的工作环境。
nvarchar可以安全地使用与varchar比较，以使我们的代码无错误（types不匹配），因为nvarchar允许unicode字符。 此外，在SQL Server查询的条件，我怀疑我碰到一些时间=在SQL Server中抛出exception，但LIKE不。 这是我认为的主要原因。
