SQL Server-執行完全匹配時，nvarchar（max）全文索引有用嗎？

Question

我在nvarchar（max）類型的表中有一列，在某些情況下，我需要對該列的內容執行完全匹配。

我知道我可以創建一個全文索引，從廣義上講，據我所知，它可以使文本標記化，從而允許在字符串中進行搜索時進行更有效的查詢。 我想知道在執行精確匹配時，就提高性能而言，全文索引是否真的有用？

有更好的選擇嗎？

Answer 1

我知道這是一個老問題，我會評論JNK的答案，但我沒有代表這樣做。

首先，由於您使用的是Nvarchar，因此必須非常小心，以確保在排序規則散列中比較相等的字符串相等； 除非您使用二進制排序規則，否則除非您的哈希算法支持Unicode或先對字符串進行規范化，否則不會發生這種情況。 Unicode允許使用相同字符的不同表示形式，例如É可以表示為代碼點U + 00C9，也可以表示為代碼點U + 0045（E），后跟代碼點U + 0301（組合急性）。

其次，像MD5這樣的密碼哈希算法與此處的哈希算法不能很好地匹配，因為哈希算法是為了性能而不是安全性。 您不需要在每次插入操作和每次查詢開始時都花那么多的CPU，也不需要索引鍵那么大。 您幾乎想要的就是.NET StringComparer.GetHashCode（）函數，該函數非常快，它說明邏輯上但二進制不相等的字符，並生成一個小的哈希碼，因此可以非常快速地對其進行比較。 遺憾的是，MS保留隨時更改該算法的權利，這將破壞所有存儲的哈希。 無論如何，如果您要使用CLR，我可能建議您從Mono項目中竊取適當的GetHashCode實現-它們的類庫是MIT許可的，因此只要您在源中保留版權聲明，就可以隨意取消它們。

Answer 2

如果您只需要檢查完全匹配，則可以創建一個計算列，該列是nvarchar(max)字段的哈希值。

這將足夠小以使其可索引，但仍將指示字段是否完全匹配。

總體思路是：

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