VARCHAR不存储Unicode字符 .
NVARCHAR存储Unicode字符 .
今天的应用程序应始终与Unicode兼容 .
NVARCHAR需要两倍的空间来存储它 .
第4点无关紧要，因为存储空间非常便宜 .
Ergo：今天设计SQL Server数据库时，应始终使用NVARCHAR .
这听起来有道理吗？有没有人不同意任何前提？今天有没有理由在NVARCHAR上选择VARCHAR？
正如其他人所指出的那样，不仅仅是存储成本 .
列的长度将影响每页的行数 . 每页的行数减少意味着您的缓存中可以容纳更少的行，这会降低性能 . 我假设在MSSQL中，索引的NVARCHAR列将占用索引中更多的空间 . 这意味着每个块的索引条目越少，因此索引中的块越多，因此在扫描（或搜索）索引时会有更多的搜索，这也会降低索引访问的速度 .
所以它在每一个方面都会失去你的表现 . 如果你真的不关心（或者可以衡量表现并且对它感到满意），那就没关系了 . 但是，如果您真正需要存储unicode字符，当然要使用NVARCHAR .
我可能认为在整个数据库中使用NVARCHAR所获得的可维护性超过任何性能成本 .
您将数据类型与将存储在列中的数据相匹配 . 通过类似的参数，您可以说为什么不将所有数据存储在NVARCHAR列中，因为数字和日期可以表示为数字字符串 .
如果将存储在列中的数据的最佳匹配是VARCHAR，则使用它 .
它不仅仅是存储，而是带宽 - CPU，内存，备份，恢复，传输 . 养护 .
我会说仍然有正当理由不使用nvarchar .
存储空间非常宝贵，例如在共享主机上，或者数据库非常庞大 .
表现至关重要 .
Brownfield开发（即数据库具有使用varchar的现有表） .
您正在与另一个只能理解单字节字符和/或varchar的旧系统集成 .
但是，新开发应该使用nvarchar esp . 因为64位系统正在成为常态 . 此外，公司（即使是小公司）现在更普遍是全球性的 .
对于许多不同类型的列，您应该为NVARCHAR选择VARCHAR，并且选择将基于每列 .
不需要NVARCHAR额外开销的典型列将是：
ID类型列：车牌，SSN，患者图表标识符等 .
代码栏：国际货币代码（USD，UKP等），ISO国家代码（美国，英国等），语言代码（en-us等），会计分部代码等
邮政编码和邮政编码列 .
我相信nvarchars的比较比varchars更昂贵，因此它非常有效，甚至在你真正不需要unicode功能的地方，甚至是一些内部ID .
而且存储成本仍然是 does matter . 如果你有数十亿行，那么"small"差异会变得非常快 .
这些问题总是有相同的答案： it depends . 你应该盲目追随没有神奇的规则 . 即使在现代编程语言中使用GOTO也是合理的：Is it ever advantageous to use 'goto' in a language that supports loops and functions? If so, why?
所以答案是：用你的头脑思考特定的情况 . 在这个特定的实例中，请记住，如果结果证明您的需求发生了变化，您始终可以在数据库中将varchar转换为nvarchar .
我看到nvarchar列转换为varchar有两个原因：
应用程序正在使用MSSQL Express Edition ，它具有4GB的数据库大小限制 . 如果有许多数据库部署，切换到MSSQL标准版的成本太高，单租户webapps或嵌入式DBMS应用程序也是如此 . 更便宜的SQL2008网络版可以在这里提供帮助 .
nvarchar(4000) is not enough 但你不想要一个ntext列 . 所以你转换为varchar（8000） . 但是，在大多数情况下，您可能应该转换为nvarchar（max） .
你的观点3是无效的 . 仅针对单个国家/地区设计的系统必须担心unicode，并且某些语言/产品正在使用中不支持unicode或仅支持部分unicode . 例如，TurboTax仅适用于美国（即使加法语版本仍然只是LATIN-1），所以他们不会支持它（我只是一个例子） .
“今天的应用程序应始终与Unicode兼容 . ”
可能更有效表达为：
“今天的应用程序应该始终是Unicode兼容的，如果没有特别需要正确处理Unicode，并且以前存在的代码库或应用程序的任何其他部分不需要专门更新以支持它”
存储比以往任何时候都要便宜，但如果你能在给定的硬盘上存储两倍的数据，这仍然很有吸引力，不是吗？
还有用于缓存的RAM和固态驱动器，它们都比硬盘驱动器贵很多 . 当您有数百万行时，使用更紧凑的数据格式是有益的 .
您的数据库服务器有没有办法使用UTF-8作为编码？然后，您可以获得主要是ASCII加载的低存储优势，并能够存储Unicode范围内的任何内容，以便可以进行扩展 .
我会要求您的数据库供应商支持UTF-8作为 VARCHAR SQL类型的编码 . 我不知道其他数据库服务器是如何做到的，但我知道你可以在至少MySQL和PostgreSQL的 VARCHAR 和 TEXT 字段中使用UTF-8 .
VARCHAR
TEXT
尽管如此，使用UTF-16编码字段的唯一原因是，如果您必须与将破坏UTF-16输入的应用程序进行交互 . 这将是大多数遗留应用程序，旨在处理ASCII或ISO-8815文本编码，这将更好地处理UTF-8 .
我不是这方面的专家 . 但是你有什么理由不能使用UTF-8来获得小空间和unicode的组合？
我见过一些数据库，其中索引（索引？...不同的争论）比数据大 . 如果一个人可以在索引中获得一半的存储需求（varchar），那么假设它等于给定页面的命中密度的两倍，并且更有效的填充因子导致更快的数据检索/写入/锁定和更少的存储要求（已经提到了） .
我倾向于“使用NVARCHAR”作为默认值......但是@CadeRoux有一个好点：如果你确定数据永远不会包含任何东西而不是ASCII - 就像美国牌照一样 - VARCHAR可能会为你节省一点点成本 .
对于任何有名字（人物，街道，地方）或自然语言文本（电子邮件，聊天，文章，博客帖子，照片 Headers ）的内容，我会说他的好评声明的另一面是"DO use NVARCHAR" . 否则，您的"firstname"列将无法正确编码"François"或"José"，并且您的文本列将不允许带有"foreign" diacritcal标记的文本，或者 - 就此而言 - 非常常见的美国字符，如分标记"¢"，段落标记"¶" ，一颗子弹"•" . （因为这些都不是ASCII字符，并且没有好的，标准的方法将它们放入VARCHAR字段 . 相信我：你会伤到自己 . ）
在我参与的任何项目中，我从未因使用NVARCHAR而被责骂，因为我“在磁盘空间上浪费了太多的公司资金” . 如果我不得不重做代码或数据库架构（特别是在现场 生产环境 系统上），重新装配所花费的成本将比购买小50％的磁盘的“节省”更容易 .
要真正理解这个问题，您必须要了解ASCII，Unicode和Unicode的典型编码（如UCS-2和UTF-8） .
14 回答
正如其他人所指出的那样，不仅仅是存储成本 .
列的长度将影响每页的行数 . 每页的行数减少意味着您的缓存中可以容纳更少的行，这会降低性能 . 我假设在MSSQL中，索引的NVARCHAR列将占用索引中更多的空间 . 这意味着每个块的索引条目越少，因此索引中的块越多，因此在扫描（或搜索）索引时会有更多的搜索，这也会降低索引访问的速度 .
所以它在每一个方面都会失去你的表现 . 如果你真的不关心（或者可以衡量表现并且对它感到满意），那就没关系了 . 但是，如果您真正需要存储unicode字符，当然要使用NVARCHAR .
我可能认为在整个数据库中使用NVARCHAR所获得的可维护性超过任何性能成本 .
您将数据类型与将存储在列中的数据相匹配 . 通过类似的参数，您可以说为什么不将所有数据存储在NVARCHAR列中，因为数字和日期可以表示为数字字符串 .
如果将存储在列中的数据的最佳匹配是VARCHAR，则使用它 .
它不仅仅是存储，而是带宽 - CPU，内存，备份，恢复，传输 . 养护 .
我会说仍然有正当理由不使用nvarchar .
存储空间非常宝贵，例如在共享主机上，或者数据库非常庞大 .
表现至关重要 .
Brownfield开发（即数据库具有使用varchar的现有表） .
您正在与另一个只能理解单字节字符和/或varchar的旧系统集成 .
但是，新开发应该使用nvarchar esp . 因为64位系统正在成为常态 . 此外，公司（即使是小公司）现在更普遍是全球性的 .
对于许多不同类型的列，您应该为NVARCHAR选择VARCHAR，并且选择将基于每列 .
不需要NVARCHAR额外开销的典型列将是：
ID类型列：车牌，SSN，患者图表标识符等 .
代码栏：国际货币代码（USD，UKP等），ISO国家代码（美国，英国等），语言代码（en-us等），会计分部代码等
邮政编码和邮政编码列 .
我相信nvarchars的比较比varchars更昂贵，因此它非常有效，甚至在你真正不需要unicode功能的地方，甚至是一些内部ID .
而且存储成本仍然是 does matter . 如果你有数十亿行，那么"small"差异会变得非常快 .
这些问题总是有相同的答案： it depends . 你应该盲目追随没有神奇的规则 . 即使在现代编程语言中使用GOTO也是合理的：Is it ever advantageous to use 'goto' in a language that supports loops and functions? If so, why?
所以答案是：用你的头脑思考特定的情况 . 在这个特定的实例中，请记住，如果结果证明您的需求发生了变化，您始终可以在数据库中将varchar转换为nvarchar .
我看到nvarchar列转换为varchar有两个原因：
应用程序正在使用MSSQL Express Edition ，它具有4GB的数据库大小限制 . 如果有许多数据库部署，切换到MSSQL标准版的成本太高，单租户webapps或嵌入式DBMS应用程序也是如此 . 更便宜的SQL2008网络版可以在这里提供帮助 .
nvarchar(4000) is not enough 但你不想要一个ntext列 . 所以你转换为varchar（8000） . 但是，在大多数情况下，您可能应该转换为nvarchar（max） .
你的观点3是无效的 . 仅针对单个国家/地区设计的系统必须担心unicode，并且某些语言/产品正在使用中不支持unicode或仅支持部分unicode . 例如，TurboTax仅适用于美国（即使加法语版本仍然只是LATIN-1），所以他们不会支持它（我只是一个例子） .
“今天的应用程序应始终与Unicode兼容 . ”
可能更有效表达为：
“今天的应用程序应该始终是Unicode兼容的，如果没有特别需要正确处理Unicode，并且以前存在的代码库或应用程序的任何其他部分不需要专门更新以支持它”
存储比以往任何时候都要便宜，但如果你能在给定的硬盘上存储两倍的数据，这仍然很有吸引力，不是吗？
还有用于缓存的RAM和固态驱动器，它们都比硬盘驱动器贵很多 . 当您有数百万行时，使用更紧凑的数据格式是有益的 .
您的数据库服务器有没有办法使用UTF-8作为编码？然后，您可以获得主要是ASCII加载的低存储优势，并能够存储Unicode范围内的任何内容，以便可以进行扩展 .
我会要求您的数据库供应商支持UTF-8作为
VARCHARSQL类型的编码 . 我不知道其他数据库服务器是如何做到的，但我知道你可以在至少MySQL和PostgreSQL的VARCHAR和TEXT字段中使用UTF-8 .尽管如此，使用UTF-16编码字段的唯一原因是，如果您必须与将破坏UTF-16输入的应用程序进行交互 . 这将是大多数遗留应用程序，旨在处理ASCII或ISO-8815文本编码，这将更好地处理UTF-8 .
我不是这方面的专家 . 但是你有什么理由不能使用UTF-8来获得小空间和unicode的组合？
我见过一些数据库，其中索引（索引？...不同的争论）比数据大 . 如果一个人可以在索引中获得一半的存储需求（varchar），那么假设它等于给定页面的命中密度的两倍，并且更有效的填充因子导致更快的数据检索/写入/锁定和更少的存储要求（已经提到了） .
我倾向于“使用NVARCHAR”作为默认值......但是@CadeRoux有一个好点：如果你确定数据永远不会包含任何东西而不是ASCII - 就像美国牌照一样 - VARCHAR可能会为你节省一点点成本 .
对于任何有名字（人物，街道，地方）或自然语言文本（电子邮件，聊天，文章，博客帖子，照片 Headers ）的内容，我会说他的好评声明的另一面是"DO use NVARCHAR" . 否则，您的"firstname"列将无法正确编码"François"或"José"，并且您的文本列将不允许带有"foreign" diacritcal标记的文本，或者 - 就此而言 - 非常常见的美国字符，如分标记"¢"，段落标记"¶" ，一颗子弹"•" . （因为这些都不是ASCII字符，并且没有好的，标准的方法将它们放入VARCHAR字段 . 相信我：你会伤到自己 . ）
在我参与的任何项目中，我从未因使用NVARCHAR而被责骂，因为我“在磁盘空间上浪费了太多的公司资金” . 如果我不得不重做代码或数据库架构（特别是在现场 生产环境 系统上），重新装配所花费的成本将比购买小50％的磁盘的“节省”更容易 .
要真正理解这个问题，您必须要了解ASCII，Unicode和Unicode的典型编码（如UCS-2和UTF-8） .