[通信] sqlserverが「%keyword%」のような扱いをするときのインデックス利用の問題

文1:パーセント符号%ワイルドカード接頭辞はSQLクエリをインデックスを停止させ、代わりにテーブル全体スキャンを使わせます。 この発言は人気があります

結論は間違っています

実際、この文はあまり正確ではありません。ワイルドカード%接頭辞はSQLのインデックス検索を非常に効率的にしますが、ほとんどの場合はインデックスに行きます(全文インデックスは不要で、通常のインデックスを作成すればいい)。

[DBO]に非クラスタインデックス[Ix_index名]を作成します。 [wkf_テーブル名]
(
[db_title]  ASC
)

今すぐ処刑してください

[図書館名]からトップ10を選択 [db_id]、[db_Summary]、[db_AddDate]、[db_title]。 [dbo]。 [wkf_database] ここで[db_title]は1 descの「%dba%」の順序です

クエリプランは明確に表示されています

比較をインデックス化する前に:

例外として、複雑なクエリクエリオプティマイザはインデックスを放棄し、フルテーブルスキャンを切り替えることがあります。 これはLIKEの「%keyword%」だけでなく、クエリの複雑さにも関係しています

文2:ワイルドカード接頭辞の割合が使えば、SQLクエリはインデックスなしではなくインデックス化されます

この主張は非常に一方的であり、インデックスの99%はインデックス化しないよりもIOを削減し効率を向上させますが、インデックスを見つけた後のキーマッチングアクションは部分的にパフォーマンスを消費します。 上記の2つの図に示されているように、キーワードが容易にマッチングできれば、テーブル全体スキャンは迅速にデータを検出し、インデックススキャンはキーマッチングの時間を補うほどの時間を節約できません(ほとんどのオンラインクエリにはこの問題はありません)。
治療:
1. 気にしなければ、追加のパフォーマンス消費はそれほど大きくありません。 キーワードによって消費量も異なりますが、一部のキーワードはこの問題を抱え、無視してもよいのです
2. 条件が許せば、オーバーライドインデックス(INCLUDEインデックスとも呼ばれる)を構築するのがより良い方法です。 前提:a. ストレージ容量が十分であること、bがDML操作に大きな影響を与えないこと、cが上書きインデックスに大きなフィールドを持たないこと

[DBO]に非クラスタインデックス[Ix_index名]を作成します。 [wkf_テーブル名]
(
[db_title]  ASC
)
INCLUDE ([db_id]、[db_Summary]、[db_AddDate])

現時点での実行クエリ計画は以下の通りで、はるかに新鮮です

上記は、今思いつくSQLSERVER処理の方法です。テーブル名から**、例えば「%Keyword %」のように。