私はテーブルにnvarchar（max）型のカラムを持っていますが、そのカラムの内容を完全に一致させる必要があるシナリオがいくつかあります。SQL Server - 完全一致を実行する場合に使用するnvarchar（max）フルテキストインデックス？
私は理解しているように、文字列内で検索したいときに、より効率的なクエリを可能にするテキストをトークン化する全文索引を作成できます。正確な一致を実行するときに、フルテキストインデックスが実際にパフォーマンスを向上させるという意味で使用されているかどうかは疑問でした。
もっと良い選択肢はありますか？
完全一致であることを確認する必要がある場合は、nvarchar(max)フィールドのハッシュである計算列を作成できます。
これは索引付け可能なほど小さくなりますが、フィールドが正確に一致するかどうかを示します。
一般的な考え方は次のようになります。
ALTER TABLE MyTable
ADD HashField as HASHBYTES('MD5', LongfieldName)
私はこれが古い質問ですけど、私はJNKの答えにコメントだろうが、私はそうする担当者を持っていない...
まず、Nvarcharを使用しているので、照合ハッシュで等しく比較される文字列が等しくなるように注意する必要があります。バイナリ照合を使用している場合を除き、ハッシュアルゴリズムがUnicode対応であるか、最初に文字列を正規化しない限り、これは起こりません。 Unicodeでは、同じ文字をさまざまに表現できます。たとえば、ÉはコードポイントU + 00C9、コードポイントU + 0045（E）、コードポイントU + 0301（急性結合）として表すことができます。
第2に、MD5のような暗号化ハッシュアルゴリズムは、セキュリティではなくパフォーマンスのためにハッシュしているここのニーズとよく一致しません。すべての挿入物とすべてのクエリの最初に多くのCPUを費やす必要はなく、インデックスキーをそれほど大きくする必要はありません。あなたが望むのはです。ほぼ .NET StringComparer.GetHashCode（）関数は高速ですが、論理的にはバイナリではない文字を扱い、小さなハッシュコードを生成し、非常に迅速に比較することができます。悲しいことに、MSはそのアルゴリズムを自由に変更する権利を留保しています。とにかくCLRに行くなら、Monoプロジェクトから適切なGetHashCode実装を盗むことをお勧めします。クラスライブラリはMITでライセンスされているので、ソースの著作権表示を保持している限り自由に持ち上げることができます。
ありがとうございます、これは正しい方向に私を指摘しています！ – user1085351
+1 - 私はあなたがそれを行うことができるとは思わなかった。 Nice – Lamak
今後の研究では、Hashbytesは最大8000文字のハッシュ文字列のみを扱うことが示されています。だから、NVARCHAR（MAX）を使って作業するときだけに依存することはできません。 – user1085351