sql-server - Unicode 和性能

Question

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

我团队中的另一个人现在想要进行负载测试，以确保所有更改都不会对系统性能产生不利影响。上述过渡的各个组成部分并没有真正暗示任何性能变化，坦率地说，根据我有限的知识，我认为这不是完全必要的。无论如何，我打算这样做，但我的问题是，在这样的迁移中，人们可能会看到任何性能问题吗？是否有任何特定于不同字符编码的东西可能会改变系统的性能？

我唯一能想到的就是繁重的字符串比较和排序等。有什么想法吗？

Answer 1

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

Unicode compression in SQL Server 2008 R2 uses an implementation of the Standard Compression Scheme for Unicode (SCSU) algorithm to compress Unicode values that are stored in row or page compressed objects. For these compressed objects, Unicode compression is automatic for nchar(n) and nvarchar(n) columns. The SQL Server Database Engine stores Unicode data as 2 bytes, regardless of locale. This is known as UCS-2 encoding. For some locales, the implementation of SCSU compression in SQL Server 2008 R2 can save up to 50 percent in storage space.

您将遇到的最大陷阱是数据类型优先规则。因为 NVARCHAR 的优先级高于 VARCHAR，所以任何混合这两者的表达式都将被强制转换为 NVARCHAR。实际上，这意味着列 A 和列 B 之间的连接条件之前位于两个 VARCHAR 列之间并导致索引查找，现在它将位于 CAST(A as NVARCHAR) 和 B 之间(考虑我们只将 B 更改为 NVARCHAR)并且这不再是 SARGable(将导致表扫描)。这个问题可能出现在联接、WHERE 子句、参数类型和许多其他地方。需要仔细考虑，导致的性能下降是巨大的(全扫描与查找)。