問題タブ [covering-index]

テーブルをまったくチェックせずに、インデックスのみを使用してクエリに応答する必要があるカバリング インデックスを持つテーブルがあります。実際、IN() 句に 1 つまたはいくつかの要素が含まれている場合、Postgres はそれを行います。ただ、IN句の要素が多い場合は、インデックスで検索して、テーブルに行って条件を再チェックしているように見えます...

なぜPostgresがそうするのか理解できません。インデックスから直接クエリを提供できるか、そうでないかのどちらかです.(理論的には)他に追加するものが何もないのに、なぜテーブルに行くのでしょうか?

テーブル：

私が実行しているクエリは次のとおりです。

ご覧のとおり、インデックスには、そのクエリに応答するために必要なすべてのフィールドがあります。

IN 句に 1 つまたは数個の数字しかない場合は、次のようになります。

1 番号:

  phone_numbers で index_phone_numbers_on_hashed_phone_number を使用したインデックス スキャン( cost=0.41..8.43 rows=1 width=4
  )

3 つの数字:

Index Only Scan using index_phone_numbers_covering_hashed_ghost_and_user on phone_numbers (cost=0.42..17.29 rows=1 width=4)
  Index Cond: ((hashed_phone_number = ANY ('{8228a8116f1fdb12e243102cb85ecd859ebf7873d9332dce5f1343a481ec72e8,43ddeebdca2ea829d468d5debc84d475c8322cf4bf6edca286c918b04216387e,1578bf773eb6eb8a9b57a130922a28c9c91f1bda67202ef5936b39630ca4cfe4}'::text[])) AND (.. .)
  フィルタ: (ゴーストではない)"

ただし、IN 句に多数の数値がある場合、Postgres はインデックスを使用していますが、テーブルにヒットします。その理由はわかりません。

Bitmap Heap Scan on phone_numbers (cost=926.59..1255.81 rows=106 width=4)
  Recheck Cond: ((hashed_phone_number)::text = ANY ('{b6459ce58f21d99c462b132cce7adc9ea947fa522a3849321e9fb65893006a5e,8228a8116f1fdb12e243102cb85ecd859ebf7873d9332dce5f1343a481ec72e8,ab3554acc1f287bb2e22ff20bb855e19a4177ef552676689d217dbb2a1a6177b,7ec9f58 (...)
  Filter: (NOT ghost)
  -> Bitmap Index Scan on index_phone_numbers_covering_hashed_ghost_and_user (cost=0.00..926.56 rows=106 width=0)
        Index Cond: (((hashed_phone_number)::text = ANY ('{b6459ce58f21d99c462b132cce7adc9ea947fa522a3849321e9fb65893006a5e,8228a8116f1fdb12e243102cb85ecd859ebf7873d9332dce5f1343a481ec72e8,ab3554acc1f287bb2e22ff20bb855e19a4177ef552676689d217dbb2a1a6177b,7e (... )

これは現在、合計 50,000 行のテーブルで 250 レコードを検索するこのクエリを作成しています。これは、500 万行のテーブルで 250 レコードを検索する別のテーブルの同様のクエリよりも約 2 倍少なくなります。理にかなっています。

何が起こっているのか、これを改善するために何かできるかどうか、何か考えはありますか?

UPDATE : カバリング インデックスの列の順序を最初にゴースト、次に hashed_phone_number に変更しても解決しません。

Bitmap Heap Scan on phone_numbers (cost=926.59..1255.81 rows=106 width=4)
  Recheck Cond: ((hashed_phone_number)::text = ANY ('{b6459ce58f21d99c462b132cce7adc9ea947fa522a3849321e9fb65893006a5e,8228a8116f1fdb12e243102cb85ecd859ebf7873d9332dce5f1343a481ec72e8,ab3554acc1f287bb2e22ff20bb855e19a4177ef552676689d217dbb2a1a6177b,7ec9f58 (...)
  Filter: (NOT ghost)
  -> Bitmap Index Scan on index_phone_numbers_covering_ghost_hashed_and_user (cost=0.00..926.56 rows=106 width=0)
        Index Cond: ((ghost = false) AND ((hashed_phone_number)::text = ANY ('{b6459ce58f21d99c462b132cce7adc9ea947fa522a3849321e9fb65893006a5e,8228a8116f1fdb12e243102cb85ecd859ebf7873d9332dce5f1343a481ec72e8,ab3554acc1f287bb2e22ff20bb855e19a4177ef55267668 (...)

3 つの列 A、B、C を持つテーブル t1 があるとします。ここで、(A,B) は一意のキー (数十万行) を構成します。クエリの 90% は SELECT C FROM t1 WHERE A=? という形式になるためです。と B =? の場合、A、B、および C のカバリング インデックスが必要だと思います。

C を含み、(A,B) を一意として定義するカバリング インデックスを作成するにはどうすればよいですか?

1つは一意で、もう1つはカバーし、INDEXED BYを使用してSELECTSのカバーインデックスを強制します。

これは合理的ですか？

以下の構造のテーブルがあります。

この SELECT クエリのカバリング インデックスを作成したいと考えています。

インデックスがメモリ キャッシュに格納されるため、インデックスをカバーすることでディスク I/O の量が削減され、パフォーマンスが向上することを理解しています。

私の SELECT クエリでは、Id をインデックスにしても、WHERE 句が Telephone_Number 値にアクセスする必要があるため、ディスク I/O の必要性がなくなるわけではないというのは正しいでしょうか?

もしそうなら、複合指数は(Id, Telephone_Number)カバリング指数として機能しますか? または、カバーするインデックスは単一の列でなければなりませんか?

Azure でホストされている MS Sql データベースを継承しました。パフォーマンスの向上を求めて、インデックス作成とインデックスのカバーについてよく読んでいます。(おそらく、これは私が見つけた中で最も完全な読み物です: https://www.red-gate.com/simple-talk/sql/learn-sql-server/using-covering-indexes-to-improve-query-パフォーマンス/ )

しかし、まだ1つの疑問が残っています...

たとえば、以下の課金テーブル (約 800 万行あります) の場合、クエリの where 句で最も使用されるフィールドは (結合内かどうかに関係なく) であることがわかりました PAYMENT_DATE, DUE_DATE, CUSTOMER_ID, DELAY_DAYS, AMOUNT 。

さらに、最適化のためのターゲット クエリは、select 句で計算を行います AMOUNT, DELAY_DAYS, COUNT(ID)。例えば：

したがって、次のインデックスがすべての問題を解決することは明らかでした。

対照的に、Management Studio でクエリ プランを要求すると、SQL Server はこのインデックスを使用せず、新しいインデックスを作成することを提案します。

したがって、疑問は次のとおりです。
カバーするインデックスは、正確に WHERE 句が検索するものである必要がありますか?
それが本当なら、カバリング インデックスが複数のクエリを満たすにはどうすればよいでしょうか?
そうでなければ、以前のインデックスがクエリを満たさないのはなぜですか?

どこで何かを見逃したのか本当にわかりません...

前もって感謝します！

Oracle Sql Developer (Data Modeller) バージョン 4.1.5.21 でカバリング インデックス (INCLUDE オプション) を構成する方法について誰か助けてください。通常のインデックスを作成するか、インデックス スクリプトを直接配置できる「インデックス式」を使用するオプションしか見つかりませんでした。

目標は、ツール自体を使用してカバーされたインデックスを構築し、たとえば、列名を変更すると、ddl の作成時にインデックスに自動的に反映されるようにすることです。

ありがとうモイナック・ロイ