web-dev-qa-db-ja.com

テキストまたはNVARCHAR(MAX)フィールドのインデックス戦略

次のクエリがあります(質問では簡略化しています)読み取り専用のDBを高速化しようとしています...

SELECT 
 [sysid]
,[Date]=CONVERT(CHAR, DATEADD(D, [date], '1800-12-28'),101)   
,[From]=[from_addr]   
,[To]=[to_addr]  --I'm a very long Text or NVARCHAR(MAX) Field
,[Subject]=[subject]  
,CASE WHEN [attach] = 1 THEN 'Yes' ELSE 'No' END AS 'Att'   
,[Code]=[ccode]   
,[Staff]=[staff]  
,[MatNo]=[mat_no]  
FROM dbo.[email] 
DYNAMIC WHERE CLAUSE ON ANY OF ABOVE

カバーするインデックスを含むいくつかのインデックスを追加しようとしましたが、to_addrをそのままでは(テキストまたはNVARCHAR(MAX)colとして)含めることができません。また、to_addrフィールドが含まれていないため、クエリオプティマイザーはクラスター化インデックスを使用してしまいます。このような状況に対処する方法は何ですか?残念ながら、これについては2005年に制限されています。

編集する

Full_Text For to_addrを追加しようとしても、テーブルスキャンは実行されます。ただし、その行をコメント化すると、インデックスが使用されます。 :(くそーテキストデータ!

2
bumble_bee_tuna

スキャン以外のことを考えて、すべてのデータを取り戻す必要があるのはなぜですか。フルテキストインデックスは実際には役立ちません-それは役立ちますsearchこれらの列ですが、すべてのデータを返す場合(あらゆるWHERE句の場合)、すべてを読み取るショートカットはありません。データの。なぜto_addrは、SMTP標準(おそらくどの標準に依存するか)によって〜320文字に制限されていると思われますが、4000文字を超えるデータが含まれていますか?

多くの人はスキャンが悪いと思っています。大量のデータを返す必要がある場合、多くの場合、クラスター化インデックススキャンが使用されます。 where句によって、返される行を見つけるためにシークが使用される可能性がありますが、その列のデータがそれほど大きい場所ではシークは機能しません。実行計画にスキャンが表示され、それが問題であると想定していますか?

5
Aaron Bertrand