問題タブ [covering-index]

現在、Lat / Long float列を含むテーブルと、これら2つの列のインデックスと取得する必要のある別の列があるサイトがあります。

私は常にこのテーブルをクエリして、特定のポイントから半径内にある行を取得しています（実際には速度のために正方形を取得しています）が、すでにインデックスが作成されているフィールドのみが必要なので、このインデックスは実際にカバーしています、および実行プランには2つのステップしかありません。

現在、SQL 2008の空間機能を利用しようとしています。地理列を作成し、それを埋め、空間インデックスを作成しました。

また、実行プランに100万ステップがあり、時間の74％がクラスター化インデックスシークに費やされ、空間インデックスで見つかった行を実際のテーブルに結合して残りを取得することを除いて、すべて正常に機能します。データの...
（空間インデックスシークは実行プランコストの1％を占めます）

したがって、明らかに、Spatialインデックスを適切に使用し、Lat / Longの「通常の」インデックスを使用して、以前よりもはるかに高速に必要なレコードを検索していますが、メインテーブルへの結合はKILLING meであり、Spatialクエリは7倍かかります。私の古いものと同じくらい。

空間インデックスに列を追加して、それがカバーされ、以前と同じように1つのステップで実行できるようにする方法はありますか？
この状況を改善するために私ができる他のことはありますか？

更新：「通常の」インデックスは、INCLUDEキーワードを使用して他の列を「含める」ことができることがわかりました（これは知らなかったので、以前はインデックス自体に列を含めるだけでした）ここ
のドキュメントによると、その句はそうではありません空間インデックスのオプション...何かアイデアはありますか？

ありがとう！
ダニエル

例えば：

IX_Aは冗長であるため、安全に削除できます。代わりにIX_ABが使用されます。これが一般化するかどうか知りたい：

私が持っている場合：

など、

小さい方のインデックスは引き続き安全に削除できますか？つまり、IX_ABCはIX_ABを冗長にし、IX_ABCDはIX_ABとIX_ABCの両方を冗長にしますか？

インデックスをカバーする際に余分な列を特定する方法はありますか? 検索対象とならないため、Includes に抽出されるか、インデックスの適用性に影響を与えずに完全に削除される可能性がある列です。

このインデックスがあるとします

これは、インデックスページと実際のデータページの両方にc2があることを意味しますか？本当の問題は、c2を更新するということは、SQL ServerがIX_testと実際のデータ行（クラスター化インデックス）を更新する必要があるということですか？

次のように luTab から myTab を更新する必要があるとします。

luTab は 2 つの列 (idLookup(unique)、LookupValue) で構成されます。

idLookup の一意のクラスター化インデックス、または idLookup と Lookupvalue の組み合わせのどちらが望ましいですか? この状況でカバリングインデックスは何か違いを生むでしょうか?

（私は主にSQLサーバーに興味があります）

エピローグ :

以下の Krips テストを、myTab で 2700 万行、luTab で 150 万行でフォローアップしました。重要な部分は、インデックスの一意性にあるようです。インデックスが一意として指定されている場合、更新ではハッシュ テーブルが使用されます。一意として指定されていない場合、更新は最初に idLookup (ストリーム アグリゲート) によって luTab を集約し、次にネストされたループを使用します。これははるかに遅いです。拡張インデックスを使用すると、その LookupValue が一意であると SQL が保証されなくなり、はるかに低速なストリーム集約ネスト ループ ルートが強制されます。

最近、私が管理しているデータベースで、次の形式のインデックスに遭遇しました。

この特定のケースでは、私が遭遇したパフォーマンスの問題 (Id と SubId の両方での低速な SELECT フィルタリング) は、SubId 列をインクルード列としてではなく、適切なインデックスに移動するだけで修正できました。

しかし、これは、一般に、それらが単にインデックス自体の一部である可能性がある場合に、含まれる列の背後にある理由をまったく理解していないと私に考えさせました。アイテムがインデックス自体に含まれていることを特に気にしなくても、単に含まれているのではなく、インデックスに列があることにはマイナス面があります。

いくつかの調査の後、インデックス付きの列に入れることができるものには多くの制限があることに気付きました (インデックスの最大幅、および「画像」のようにインデックスを作成できないいくつかの列の種類)。これらの場合、索引ページのデータに列を含める必要があることがわかります。

私が考えることができる唯一のことは、SubId に更新がある場合、列が含まれていれば行を再配置する必要がないということです (ただし、インデックスの値を変更する必要があります)。私が見逃しているものは他にありますか？

データベース内の他のインデックスを調べて、可能な場合は適切なインデックスに含まれる列をシフトすることを検討しています。これは間違いでしょうか？

私は主に MS SQL Server に興味がありますが、他の DB エンジンに関する情報も歓迎します。

以下はいつ必要になりますか。

従業員データベースをダウンロードし、ベンチマークの目的でいくつかのクエリを実行しました。
次に、以前に作成した対応するインデックスがあったにもかかわらず、1つのクエリがカバーインデックスを使用していないことに気付きました。FORCE INDEXクエリに句を追加した場合にのみ、カバーインデックスが使用されました。
2つのファイルをアップロードしました。1つは実行されたSQLクエリで、もう1つは結果です。句が追加され
たときにのみクエリがcovering-indexを使用する理由を理解できますか？FORCE INDEXEXPLAINは、どちらの場合も、インデックスdept_no_from_date_idxがとにかく使用されていることを示しています。

SOの標準に適応するために、2つのファイルの内容もここに書き込んでいます。

SQLクエリ：

結果：

編集：
最後の2つのクエリの間には、実行速度にかなりの違いがあることに気づきました。結果はあなたの前に配置されます。

ただし、実行順序を変更すると（最後のクエリを最初に実行し、最初のクエリを最後に実行する）、実行速度は同じになります。

SQL_NO_CACHEは両方のクエリに書き込まれるため、2番目のクエリがキャッシュから取得されている可能性はありません。では、最初の例では最初のクエリに0.31秒、2番目のクエリに0.06秒かかったのに、2番目の例では両方のクエリに0.08秒かかるのはなぜですか？

Edit2：
実行速度の違いは、OSキャッシュやその他の要因によるものだと思います。上記2つのクエリを繰り返し実行すると、実行時間の差はごくわずかになります。上記の2つのクエリを3回繰り返し実行したところ、次の結果が得られました。

私はデータベース システムに取り組んでおり、それはインデックスですが、カバリング インデックスとクラスター化インデックスの明確な違いを理解するのに非常に苦労しています。

私は自分の道をグーグルで検索しましたが、明確な答えがありません:

1. 2 種類のインデックスの違いは何ですか
2. いつカバリング インデックスを使用し、いつクラスター化インデックスを使用しますか。

誰かがほとんど子供のような答えで私に説明してくれることを願っています:-)

メスティカ

ちなみに、IBM DB2 バージョン 9.7 を使用しています。

毎月着実にサイズが大きくなっているテーブルへのインデックスのゲインと、インデックスを使用したクエリのゲインとの間の微妙な境界線について質問があります。

状況は、Table1とTable2の2つのテーブルがあるということです。各テーブルはゆっくりと、しかし毎月定期的に増加します（Table1には約100の新しい行があり、 Table2には2つの行があります）。

私の具体的な質問は、インデックスを作成するか、削除するかです。Table2のカバーインデックスがSELECTクエリを改善することを測定しましたが、ここでも、長所と短所を考慮する必要がありますが、決定するのは非常に困難です。

Table1の場合、SELECTクエリはそれほど一般的ではないため、インデックスを作成する必要がない場合があります。

良い解決策についての提案、ヒント、または単に良いアドバイスをいただければ幸いです。ちなみに、データベースシステムとしてIBMDB2バージョン9.7を使用しています

心から

メスティカ