使用数据库大约5年后，我发现最终，我遇到了varchar字段性质有限的问题，我不得不修改字段以将数据存储为nvarchars。在不得不对表进行另一次更新，将varchar字段转换为nvarchar之后，我有了一个想法-为什么我们仍要这样做呢？我很早就做出了将所有新的文本字段都定义为nvarchar而不是varchar的决定，这是我10年前上学时从课本中学到的。
是2011年，去年有一个新版本的SQL Server。当可以/应该使用nvarchar时，为什么为什么继续支持varchar数据类型？
我知道，经常有人争辩说nvarchars是varchars的“两倍大”，因此存储空间的使用可能是维护varcars的观点之一。
但是，今天的用户如果想节省存储空间，可以定义其nvarchars将数据存储为UTF-8而不是默认的UTF-16。如果主要需要的话，这将允许进行8位编码，同时确保插入到其DB中的罕见2-8字节字符不会破坏任何内容。
我错过了什么吗？在过去15到20年中这种情况没有发生变化，这是否有充分的理由？
#1 楼
varchar的工作足以应付许多西欧语言（挪威语，丹麦语，德语，法语，荷兰语等），但会遇到一些归类问题
在SO上查看此内容varchar vs nvarchar性能nvarchar的性能很出色含义
与处理日期MDY和DMY相比，这是微不足道的
#2 楼
除了解决标准和兼容性的答案外，还应牢记性能。尽管人们很容易接受磁盘空间便宜，但是DBA /开发人员经常忽略这样一个事实，即查询性能有时与表的行/页大小直接相关。使用NVARCHAR而不是VARCHAR（必要时）将有效地使字符字段的行大小加倍。如果您有5个或10个50个长度的字段，那么您正在谈论可能在每行增加500个字节。如果您有一张宽桌子，这可能会将每一行推到多页中，并对性能产生不利影响。#3 楼
仍然有大量组织使用假定为单字节字符的应用程序，接口，平台和工具建立了庞大的基础。数据库很少孤立存在-它们是IT生态系统的一部分。如果您有成千上万个依赖于单字节字符的组件和数百万行代码，那么您将有充分的理由投资切换到unicode所需的时间和金钱。这种规模的变更可能需要数年才能完成。在某些地方，Unicode还是相对较新，很少见或不完全受支持的。VARCHAR和NVARCHAR都是ISO标准SQL的一部分。删除或弃用SQL Server中的VARCHAR支持将是兼容性和可移植性方面的倒退。
#4 楼
或者，今天的用户如果想节省存储空间，则可以定义其nvarchars将
数据存储为UTF-8而不是默认的UTF-16。
这正是大多数开源数据库对
VARCHAR所做的工作。MySQL提供了
utf8和ucs2“排序规则”。SQLite允许您在UTF-8（默认值）和UTF-16之间选择。
PostgreSQL支持UTF-8（但不支持UTF-16）。
否需要具有两种单独的字符串类型。
微软很奇怪，因为它认为8位字符串用于旧式编码，而Unicode = UTF-16。这可能与Windows API本身以这种方式处理
char和wchar_t有关。