SQL Server - nvarchar（最大）全文索引在进行精确匹配时有用吗？

我在表中有一列是nvarchar（max）类型的列，并且有一些场景需要对该列的内容执行完全匹配。SQL Server - nvarchar（最大）全文索引在进行精确匹配时有用吗？

我知道我可以创建一个广义上讲全文索引，按我的理解，tokenises文字让更高效的查询想在字符串中搜索时。我想知道，在进行完全匹配时，全文索引是否实际上在增加性能方面有任何用处？

有没有更好的选择？

2011-12-21 user1085351

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

这将是小到可转位，但仍然表明，如果字段精确匹配与否。

总体思路是：

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

来源

2011-12-21 13:30:14 JNK

谢谢，这已经指明我在正确的方向！ – user1085351 2011-12-21 13:33:18

+1 - 我从来没有想过你可以做到这一点。 Nice – Lamak 2011-12-21 13:35:36

进一步的研究表明，Hashbytes只会散列长度高达8000的字符串。所以在使用NVARCHAR（MAX）时不能仅依靠它。 – user1085351 2011-12-21 14:04:54

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

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

其次，如MD5加密哈希算法不与需求匹配以及在这里，在这里你哈希性能没有保障。你不需要在每个插入和每个查询的开始都花费太多的CPU，并且你不需要你的索引键那么大。你想要的是差不多 .NET StringComparer.GetHashCode（）函数很快，它占用逻辑上不是二进制数的字符，并生成一个小的哈希码，因此可以非常快速地进行比较。令人遗憾的是，MS保留随意更改该算法的权利，这将破坏任何存储的哈希。无论如何，如果你要去CLR，我可能会建议从Mono项目中窃取适当的GetHashCode实现 - 它们的类库是MIT许可的，所以只要你保留源代码中的版权声明，你可以随意提取它们。

来源

2012-12-12 14:38:12

SQL Server - nvarchar（最大）全文索引在进行精确匹配时有用吗？

回答

相关问题