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

VARCHAR与NVARCHAR

这取决于Oracle的安装方式。在安装过程中，将设置NLS_CHARACTERSET选项。您可以使用查询SELECT值$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！它避免了限制和依赖性，对存储空间很好，通常对性能也是最好的。

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

想象一下下面的场景。

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

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

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

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

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

我看了一下答案，许多人似乎建议使用nvarchar而不是varchar，因为空间不再是问题，所以启用Unicode以获得很少的额外存储不会有什么害处。嗯，当你想在列上应用索引时，这并不总是正确的。SQL Server对可以索引的字段的大小限制为900字节。因此，如果您有一个varchar（900），您仍然可以对其进行索引，但不能对varchar（901）进行索引。使用nvarchar，字符数减半，因此可以索引到nvarchar（450）。因此，如果您确信不需要nvarchar，我不建议使用它。

一般来说，在数据库中，我建议您坚持所需的大小，因为您可以随时扩展。例如，一位同事曾经认为，对列使用nvarchar（max）没有害处，因为我们在存储方面完全没有问题。后来，当我们试图对此列应用索引时，SQL Server拒绝了这一点。然而，如果他甚至从varchar（5）开始，我们可以简单地将其扩展到我们需要的内容，而不会出现这样的问题，这将要求我们制定一个字段迁移计划来解决这个问题。

由于SQL Server 2019 varchar列支持UTF-8编码。

因此，从现在开始，不同的是规模。

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

更少的数据=更少的IO+更少的内存=通常速度更快。阅读上面的文章了解数字。

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

只有当您拥有2048-16383和16384-65535范围内的大量字符时，您才需要测量

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

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