SQL Server 2019 UTF-8 支持优势

Question

我已经很习惯使用 COMPRESS()，并DECOMPRESS()在内部论坛软件为我公司（目前在SQL Server 2017），而是试图使数据库尽可能高效，是有一个优势，加入_UTF-8到我的当前归类为Latin1_General_100_CI_AS_SC_UTF8在未来迁移到 SQL Server 2019？

Answer 1

试图使数据库尽可能高效

至少有两种不同类型的效率在这里真正起作用：

1. 空间（磁盘和内存）
2. 速度

在某些条件下（如 Outman 的回答中所述，这是我博客文章“推荐用途/指南”部分的复制/粘贴，链接在该答案的顶部）您可以节省空间，但这完全取决于类型和每行字符数。

但是，至少在当前的实现中，您更有可能降低速度。这可能是由于他们如何在内部处理 UTF-8 数据。我知道将 UTF-8 数据与非 UTF-8VARCHAR数据进行比较时，两个值都会转换为 UTF-16 LE（即NVARCHAR）。如果其他（甚至可能是大多数）操作需要将 UTF-8 数据转换NVARCHAR为 Windows/SQL Server/.NET 一直处理 Unicode 的方式，我不会感到惊讶。

因此，假设您有一个可能受益于使用 UTF-8 的场景，您需要选择哪个效率更重要。

现在，UTF-8 是否会有益于环境本身自然是 UTF-8（例如 Linux）的场景还有待观察。通常，数据库驱动程序（ODBC、SQL Native Client 等）处理客户端和服务器之间的转换。我想如果这样做会导致驱动程序软件跳过执行这些编码转换所需的额外步骤（和 CPU 周期），那么这里可能会提高性能/效率。到目前为止，这只是一个理论，因为我还没有对其进行测试。

请记住以下几点：

1. UTF-8 旨在实现 ASCII 兼容性以便于实现。这允许基于标准 ASCII 的系统（值 0 - 127；值 128 - 255 是扩展 ASCII，不在此范围内）启用 Unicode，而无需以新编码重新保存任何内容。

   对于SQL Server，目标是当前使用现有的应用程序VARCHAR可以开始支持Unicode的，而无需做太多重新编码（即添加N前缀字符串文字），或者从更新的数据类型VARCHAR来NVARCHAR。

   它不是设计为一种压缩形式。如果您的数据在 UTF-8 中占用的空间更少，那就太好了。但是当处理不是标准 ASCII 的数据时，要么不会有任何节省，或者更糟的是，您可能会通过使用 UTF-8 来增加数据大小（假设 65k BMP 字符中的 63k 是 UTF 中的 3 个字节） -8，这比它们在 UTF-16 中需要的 2 个字节多1 个字节）。

   而且，如果 UTF-8 带来了性能提升，或者至少您没有看到性能下降，那就太好了。但是，不要指望它。事实上，如果您碰巧看到性能下降，请不要感到惊讶。

2. 如果您决定在 SQL Server 中实现 UTF-8 排序规则，则需要注意一些潜在的数据“问题”：

   1. 由于混合 UTF-8 字符串文字和/或变量（由于当前数据库具有 UTF-8 默认排序规则）和非 UTF-8VARCHAR 列而导致的数据丢失。这是由于排序规则优先级有效地将排序规则从 UTF-16 降级到列使用的任何代码页。
   2. 将非 UTF-8 字符串文字和/或变量与 UTF-8 列（以及在某些情况下，变量）混合的小截断。这是由于某些字符在 UTF-8 中需要比在原始编码中更多的字节造成的。
   3. UTF-8 中的无效字节序列可能会引发错误，而不是返回默认替换字符“ ”。这与目前在任何其他 8 位编码或 UTF-16 中处理无效序列所采用的方法不同。
       

   有关更多详细信息和示例，请参阅我的帖子：SQL Server 2019 中的本机 UTF-8 支持：救世主还是假先知？