我正在迁移大型 Web 服务以兼容国际字符。它是一个 Tomcat/Spring MVC/SQL Server 堆栈。迁移本身相对简单，我们在 Tomcat 中进行了一些设置更改以强制在响应中默认使用 UTF-8，更改了一些 Java 代码以使用编码并将一些 VARCHAR 列迁移到 NVARCHAR，然后是健康剂量单元/功能测试。
我团队中的另一个人现在想要进行负载测试，以确保所有更改都不会对系统性能产生不利影响。上面描述的这种转变的各个组成部分并没有真正暗示任何性能变化，坦率地说，基于我有限的知识，我认为这不是完全必要的。无论如何我都打算这样做，但是我的问题是，在这样的迁移中是否有任何性能问题？是否有任何特定于不同字符编码的东西可能会改变系统的性能？
我唯一能想到的就是繁重的字符串比较和排序等。有什么想法吗？
【问题讨论】：
标签： sql-server tomcat unicode spring-mvc
您应该考虑升级到 SQL Server 2008 R2，因为它提供了Unicode Compression：
SQL Server 2008 中的 Unicode 压缩 R2 使用了 标准压缩方案 Unicode (SCSU) 算法进行压缩 存储在行中的 Unicode 值 或页面压缩对象。对于这些 压缩对象，Unicode nchar(n) 的压缩是自动的 和 nvarchar(n) 列。 SQL 服务器数据库引擎存储 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 子句、参数类型和许多其他地方。需要仔细考虑，导致性能下降是巨大的（全扫描与搜索）。
【讨论】：
我只有这个轶事：
在我以前的公司中，我们遇到了数据库中的文本字段 (ASCII) 与查询中的 unicode 字符串匹配的问题。这导致 sql server 切换到表扫描而不是通常的索引，因为它不能证明字符串总是可以翻译成 ascii。这对我们来说是一个重大的性能打击。
【讨论】：
字符编码，只要处理得当，应该不是问题。 Unicode 要复杂得多，但您不会想到这一点。其他人已经这样做了。您需要考虑的只是不要以无意义的方式转换任意字符串。
然而，您会看到，您的所有字符串数据将占用两倍的空间。这确实会影响 SQL Server 用于创建执行计划的启发式方法，并且存在可能更改的索引的细微问题，但是，如果您没有非常非常大的数据集，我不会担心这一点。
【讨论】：