1

200000 レコードの Person テーブルがあるとします。その GUID プライマリ キーにクラスター化インデックスがあります。この GUID は、SQL Server (2008 R2) によって提供される NEWSEQUENTIALID() コンストラクトを使用して生成されます。さらに、LastName (varchar(256)) 列には通常のインデックスがあります。

一意の名前 (Lastname_1 から Lastname_200000 まで) を生成したすべてのレコードに対して、いくつかのクエリをいじっていて、基準がより制限的であるほど、SQL Server が実際の結果を返すのが遅くなることがわかりました。そして、このパフォーマンスへの影響は非常に深刻です。

例えば：

SELECT * FROM Person WHERE Lastname LIKE '%Lastname_123456%'

よりもはるかに遅い

SELECT * FROM Person WHERE Lastname LIKE '%Lastname_123%'

応答時間は、次の統計を設定することによって測定されます。

SET STATISTICS TIME ON

これが原因だと想像できます

1) LIKE 句自体が原因で、% で始まるため、その特定の列でインデックスを使用することはできません。

2) SQL は私の「より大きな問題」についてもっと考えなければなりません。

これに真実はありますか？これを回避する方法はありますか？

編集：この質問にコンテキストを追加するために、これは「無料検索」のユースケースの一部です。ユーザーが完全な姓を入力したときに、システムが高速であることを切望しています。

これらのケースを実行するにはどうすればよいですか? 「%xxx%」の構造を避けて、「xxx%」のような構造を使用する必要がありますか? これにより、速度が大幅に向上しますが、ユーザーの柔軟性が犠牲になります...

4

2 に答える 2

1

2 番目の LIKE は文字列内のより多くの文字に一致する必要があるため、SQL は一致しない文字を見つけると検索を停止するため、より小さな検索文字列を見つけるために文字列一致の反復が少なくて済みます。より多くの結果を取り戻します。

＃1について-SQLは可能であればLIKEにインデックスを使用しますが、ワイルドカードを使用したシークは不可能であるため、おそらくインデックススキャン（おそらくクラスター化インデックス）を実行します。また、インデックスに含まれるものにも依存します-すべての列を選択しているため、「使用できる」インデックスがクエリをカバーしていないため、代わりにテーブルスキャンが発生している可能性があります（クラスター化インデックスを使用している場合を除く）

実行計画を確認してください。テーブル スキャンが表示される可能性があります。

于 2012-06-25T10:43:40.483 に答える
0

通常、SQLServerはLIKEでインデックスを使用しません。

この記事はあなたを導くのを助けることができます

于 2012-06-25T11:17:25.943 に答える