NVarchar 与 Varchar 的对比

每个工程师在定义新的字符串列时都会面临选择：我应该使用 nvarchar 还是 varchar？

自从我发现了 nvarchar，我就一直使用 nvarchar。我的想法是，为什么要使用一个可能不支持某些文本值的数据类型，而且你很可能直到生产环境才会发现不兼容的值。

我听到过关于空间的争论，但空间很便宜，不值得担心。我知道你在想什么，当硬盘满了的时候成本就很重要了，我同意这一点。

从 Sql Server 2008 R2 开始，数据压缩被应用到 nchar 和 nvarchar（nvarchar(max) 除外）字段。根据数据的不同，压缩的效果也不同，但对于英文，有 50% 的压缩率，这使它与 varchar 的空间需求相当（1）。

另一个需要考虑的是，大多数编程语言都支持 UTF-16 作为字符串类型。所以每次从数据库加载 varchar 时，它都会被转换为 UTF-16（类似 nvarchar）

这个 StackOverflow 答案总结了 nvarchar 与 varchar 的对比：

nvarchar 列可以存储任何 Unicode 数据。varchar 列被限制在 8 位代码页。有些人认为应该使用 varchar，因为它占用更少的空间。我认为这不是正确的答案。代码页不兼容是一个痛点，而 Unicode 是代码页问题的解决方案。在如今磁盘和内存都很便宜的情况下，真的没有理由再浪费时间处理代码页问题了。

所有现代操作系统和开发平台内部都使用 Unicode。通过使用 nvarchar 而不是 varchar，你可以避免每次读取或写入数据库时进行编码转换。转换需要时间，而且容易出错。从转换错误中恢复是一个非平凡的问题。

如果你正在与只使用 ASCII 的应用程序接口，我仍然建议在数据库中使用 Unicode。操作系统和数据库排序算法在 Unicode 下工作得更好。Unicode 避免了与其他系统接口时的转换问题。而且你将为未来做好准备。你总是可以验证你的数据被限制为 7 位 ASCII，以适应你必须维护的任何遗留系统，同时仍然享受完整 Unicode 存储的一些好处。（2）

我的结论是，数据只有在静止状态时才是 varchar。

参考资料：

1. Unicode 压缩实现
2. varchar 和 nvarchar 有什么区别？