Unicode和性能

Question

我正在将一个大规模的网络服务迁移到支持国际字符。它是一个Tomcat/Spring MVC/SQL Server堆栈。迁移本身相对简单，我们在Tomcat中进行了一些设置更改，以强制默认使用UTF-8响应，在Java代码中使用编码，并将一些VARCHAR列迁移到NVARCHAR，然后进行了大量的单元/功能测试。

我的团队中还有另一个人想要进行负载测试，以确保这些更改不会对系统性能产生负面影响。上述转换的各个组件并没有暗示任何性能变化，老实说，根据我的有限知识，我认为这并不完全必要。我仍然打算进行测试，但我的问题是，此类迁移是否存在任何性能陷阱？不同字符编码是否会改变系统的性能？

我唯一能想到的可能是字符串比较和排序等操作。你有什么想法吗？

- dfb

---

感谢所有的回答，我随机选择了一个来接受，因为它们都同样出色。 - dfb

Answer 1

您应该考虑升级到SQL Server 2008 R2，因为它提供了Unicode压缩：

SQL Server 2008 R2中的Unicode压缩使用标准压缩方案实现Unicode（SCSU）算法来压缩存储在行或页压缩对象中的Unicode值。对于这些压缩对象，nchar(n)和nvarchar(n)列的Unicode压缩是自动的。SQL Server数据库引擎将Unicode数据存储为2个字节，无论所在地区如何。这被称为UCS-2编码。对于某些地区，在SQL Server 2008 R2中实现的SCSU压缩可以节省高达50％的存储空间。

您将遇到的最大问题是数据类型优先级规则。因为NVARCHAR比VARCHAR具有更高的优先级，任何混合两者的表达式都将被强制转换为NVARCHAR。实际上，这意味着A列和B列之间的连接条件，如果之前是在两个VARCHAR列之间并导致索引查找，现在将在CAST(A as NVARCHAR)和B之间（考虑我们仅将B更改为NVARCHAR），这不再是SARGable（会导致表扫描）。这个问题可能出现在连接、WHERE子句、参数类型等许多地方。需要仔细考虑，因为性能下降非常严重（全表扫描 vs. 索引查找）。

- Remus Rusanu

Answer 2

我只有一个轶事：

在我以前的公司，我们遇到了这样的问题，即数据库中的文本字段（ASCII）与查询中的Unicode字符串匹配。这导致SQL服务器切换到表扫描而不是通常的索引，因为它不能证明该字符串始终可转换为ASCII。这对我们来说是一个显著的性能损失。

- user180326

---

是的 - 我们也遇到过这个问题。如果您使用Hibernate，这尤其令人恼火，因为在当前版本中，您必须使所有列都是Unicode或全部是ASCII。 - dfb

@spinning_plate：很好，你意识到了。这通常是一件难以进行压力测试的事情，除非你制作非常大的测试数据库。 - user180326

Answer 3

字符编码，只要做得正确，就不应该成为问题。Unicode更加复杂，但你不需要考虑那些。别人已经处理好了。你需要考虑的是，不要以无意义的方式转换任意字符串。

然而，你会发现所有的字符串数据将占用两倍的空间。这确实会影响SQL Server用于创建执行计划的启发式算法，并且可能会导致索引出现微妙的问题，但如果你没有非常大的数据集，我不会担心这些问题。

- John Leidegren