从 SQL Server 中的索引中跳过一些数据

Question

我有一种情况，SQL Server 给出索引大小超过 900 字节的错误。它的发生是因为索引定义中的列之一是 varchar(2000)，并且每当其长度超过 800 时，就会出现错误。

所以，我的问题是，有没有办法在索引定义中说只包含列中的前 800 个字符？

博客上的一些人建议向表中添加一个附加列，该列将具有其他列的前 800 个字符，并在这个新的附加列而不是原始列上添加索引。但我认为这会影响整体性能，因为读取查询仍在查询原始列。

请建议是否有其他方法可以解决此问题。

Answer 1

我在这里写了一篇关于这种情况的帖子，比这个答案更深入。

有没有办法在索引定义中说只包含列中的前 800 个字符？

这可以通过创建一个计算列作为LEFT(MyColumn, 800)，然后索引该列来完成。请注意，不必使用PERSISTED子句在表中具体化该列——在该列上创建索引将仅将值具体化为索引。但是，请谨慎使用计算列方法，因为它在某些情况下可能不会像您预期的那样运行（通常是计算列的问题，并非特定于这种情况）。

这种方法允许您进行精确匹配和LIKE 'xyz%'直接匹配，只要搜索词短于索引长度即可。

您可以使用 CHECKSUM 生成一个小的哈希

CHECKSUM函数的结果可能很小，但它不是一个很好的哈希函数。改用HASHBYTES或 CLR 函数。

关于计算列，同样的事情也适用于上面。或者，这个值足够小（16 字节），可以使用触发器或应用程序代码在表中具体化并从那里索引。

缺点是这种方法只允许精确匹配，因为无法匹配部分输入，当然需要更改管理将新的非 NULL 列添加到现有表。

读取查询仍在查询原始列。

您需要更改查询访问表的方式以使这些解决方案之一起作用，因此如果这不可能，那么您就不走运了。

因为我们谈论的有损压缩（散列或截断），查询总是要还比较针对搜索词的原始值，除非该指数是由独特的，它可以打开你到用户的报告奇怪的错误（第800个字符相同或不太可能发生的哈希冲突）。如果索引不是唯一的并且未比较原始值，则可能会返回不正确的结果（注意：这可能是一个安全漏洞）。

额外的比较可能会影响查询计划，如果没有示例查询，我不会深入研究，但您可以在我上面链接的博客文章中找到一些小例子。使用您现有的表模式和查询，您应该能够对计划会发生什么做出有根据的猜测。