SQL Server - nvarchar（max）全文索引在完全匹配时有用吗？

Question

我在表中有一个类型为nvarchar（max）的列，并且在某些情况下我需要对该列的内容执行完全匹配。

我知道我可以创建一个全文索引，正如我所理解的那样，它广泛地说明文本标记，以便在想要在字符串中搜索时提供更有效的查询。我想知道，在执行完全匹配时，全文索引在提高性能方面是否实际上是否有用？

还有更好的选择吗？

Answer 1

如果你需要检查的是完全匹配，你可以创建一个计算列，它是nvarchar(max)字段的哈希值。

这个小到可以索引，但仍然会指示字段是否完全匹配。

一般的想法是：

ALTER TABLE MyTable
ADD HashField as HASHBYTES('MD5', LongfieldName)

Answer 2

我知道这是一个老问题，我会评论JNK的答案，但我没有代表这样做......

首先，既然你正在使用Nvarchar，你必须非常小心地确保在你的校对哈希中比较相等的字符串;除非您使用二进制排序规则，否则不会发生这种情况，除非您的哈希算法支持Unicode，或者您首先规范化字符串。 Unicode允许相同字符的不同表示，例如É可以表示为代码点U + 00C9，或者代码点U + 0045（E）后跟代码点U + 0301（组合急性）。

其次，像MD5这样的加密哈希算法与此处的需求并不匹配，在这种情况下，您需要对性能进行哈希处理而不是安全性。您不需要在每个插入中和每个查询的开头花费那么多CPU，并且您不需要索引键那么大。你想要的是几乎 .NET StringComparer.GetHashCode（）函数，它很快，可以解释逻辑上但不是二进制相等的字符，并生成一个小的哈希码，因此可以非常快速地进行比较。遗憾的是，MS保留随意更改该算法的权利，这会搞砸任何存储的哈希值。无论如何你都要去CLR，我可能会建议你从Mono项目中窃取相应的GetHashCode实现 - 他们的类库是MIT许可的，所以你可以随意解除它们，只要你在源代码中保留版权声明。