SQL Server 2019 UTF-8支持福利

Question

我已经非常习惯于在我们公司的内部论坛软件(目前在Server 2017中)中使用COMPRESS()和DECOMPRESS()，但为了使数据库尽可能高效，在将来迁移到Server 2019时，在当前的排序规则中添加_UTF-8是否有优势？

Answer 1

下面列出了从 这里:中获取的推荐用法列表

UTF-8编码，作为一种可变长度的编码，在某些情况下可能是一个巨大的好处，但在其他情况下也会使情况变得更糟。不幸的是，“_UTF8”编码没有多大用处，因为所有版本的Server都可以使用数据压缩和集群列存储索引。唯一真正受益于UTF-8编码的情况是，下列所有条件都为真：

1. 数据大多是标准的ASCII (值0- 127)，但是有或可能有少量的Unicode字符(比在单个8位代码页上找到的要多，或者在任何8位代码页上都不存在)。
2. 列当前(或将是) NVARCHAR(MAX) (意思是，数据不适合NVARCHAR(4000))。
3. 该列或一组列有大量数据(存储在NVARCHAR中的数据为1GB或更多)。
4. 使该表成为群集Columnstore表(由于如何使用该表)或数据通常小于8000字节会对性能产生负面影响，因此不希望使列VARBINARY( MAX )、使用COMPRESS()进行插入和更新操作，并使用DECOMPRESS()进行选择查询(无需担心无法对VARBINARY值进行索引，因为它是无法索引的最大数据)。请记住，Keep值甚至比字符串的UTF-8版本要小得多，尽管它需要解压缩才能对值进行过滤(“=”之外)或操作。
5. 减少备份的大小和缩短备份和恢复所需的时间，以及减少对缓冲池的影响，所带来的好处超过了可能对查询性能造成的负面影响( CPU和运行时间)的成本。请记住，备份压缩(在企业版和标准版中可用)在这里可能会有所帮助。

存储HTML页面是符合这种描述的场景的一个很好的例子。当然，UTF-8正是由于它使用了最常见字符的最小空间而仍然允许完整范围的Unicode字符的首选编码。

Answer 2

努力使数据库尽可能高效

至少有两种不同类型的效率在这里发挥作用：

1. 空间(磁盘和内存)
2. 速度

在某些情况下(如Outman的答案所述，它是我博客文章中“推荐使用/指导”部分的副本/粘贴，链接在该答案的顶部)，您可以节省空间，但这完全取决于字符的类型和每行数量。

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

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

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

请记住以下几点：

1. UTF-8是为实现ASCII兼容性而设计的，以便于实现。这允许基于标准ASCII的系统(值0- 127；值128 - 255是扩展的ASCII，不包括在此范围内)启用Unicode，而不必在新编码中重新保存任何内容。对于Server来说，目标是当前正在使用VARCHAR的现有应用程序可以开始支持Unicode，而无需进行太多的重新编码(即向字符串文本添加N前缀)或将数据类型从VARCHAR更新到NVARCHAR。它不是设计成一种压缩形式。如果您的数据在UTF-8中减少了占用空间，那么就很好了。但是，当处理非标准ASCII的数据时，要么没有任何节省，更糟的是，您可能会通过转到UTF-8来增加数据大小(考虑到65k BMP字符中的63k字符在UTF-8中是3个字节，这比UTF-16中所需的2个字节多了一个字节)。而且，如果UTF-8提供了性能增益，或者至少您没有看到性能下降，那么很好。不过，别指望了。事实上，如果你碰巧看到业绩下降，不要感到惊讶。
2. 如果您决定在Server中实现UTF-8排序规则，则需要注意一些潜在的数据“问题”：。
   1. 由于混合UTF-8字符串文字和/或变量(由于当前数据库具有UTF-8默认排序规则)和非UTF-8 VARCHAR列而导致的数据丢失。这是由排序规则优先级导致的，它有效地将排序规则从UTF-16降到列正在使用的任何代码页。
   2. 将非UTF-8字符串文字和/或变量与UTF-8列(在某些情况下，还包括变量)混合在一起的少量截断。这是由于某些字符在UTF-8中需要比原始编码中更多的字节。
   3. UTF-8中的无效字节序列可能引发错误，而不是返回默认的替换字符"�“。这是一种与迄今为止在任何其他8位编码或UTF-16中的无效序列不同的方法。

有关更多细节和示例，请参见我的帖子：Server 2019中的本机UTF-8支持:救世主还是假先知？中的“要记住的事情:操作”部分。