0

インデックスを追跡し、インデックスが追加されたテーブルを分析すると、いくつかの状況が発生します。一部のテーブルにはインデックスがありますが、whereインデックス フィールドの句を使用してクエリを実行すると、それぞれの idx_scan フィールドに反映されません。relname と schemaname は同じなので、間違いはありません。

さらにテストして、テーブルを削除して再度作成した後、クエリがアカウントに返されましたidx_scan

それは別のテーブルでも発生しました。インデックスを使用していくつかのクエリを実行し、idx_scan フィールドを考慮しませんでした。

これらのテーブルの問題は何ですか? 私たちは何を間違っていますか?間違っている古いテーブルに、idx_scan に含まれるインデックスを持つ新しいテーブルを作成した場合のみ。このデータベースで時々移行を行いましたが、それが問題になる可能性がありますか? ローカルホストとサーバーオンラインで発生しました。

私たちが確認した別のイベントとして、いくつかのインデックスが計上され、idx_scan > 0 であり、クエリ選択を実行すると、idx_scan が再び増加せず、数が修正され、seq_scan が増加するだけでした。それらの問題は関連している可能性があると思います。

私たちのデータベースを徘徊するのは大きな謎であり、何が問題なのかわかりません。

4

1 に答える 1

0

いくつかの提案 (および質問に追加するもの)。

1 つ目は、インデックス スキャンがシーケンシャル スキャンよりも優先されるとは限らないことです。たとえば、テーブルが小さい場合、またはほとんどのページをフェッチする必要があるとプランナーが見積もった場合、インデックス スキャンは省略され、順次スキャンが優先されます。

覚えておいてください: ディスクから単一のページを取得し、それを順次実行することに勝る計画はありません。

同様に、たとえばリレーションのページの 50% を取得する必要がある場合、インデックス スキャンを実行すると、ディスク/IO の合計がいくらか少なくなり、ランダムなディスク/IO が大幅に増えます。SSD を使用する場合は有利かもしれませんが、従来のハード ドライブを使用する場合は確かにそうではありません。結局のところ、大皿が回転するのを待ちたくありません。SSD を使用している場合は、それに応じてプランナーの設定を微調整できます。

したがって、インデックス対シーケンシャル スキャンは話の終わりではありません。問題は、取得される行数、テーブルの大きさ、取得されるディスク ページの割合などです。

それが本当に悪い計画を選んでいる場合 (考慮しなかった良い計画ではなく!)、問題はその理由になります。統計目標を設定する方法はありますが、あまり役に立たないかもしれません。

最後に、プランナは、必要に応じてインデックスを選択できない場合があります。たとえば、5 年間 (平均で年間約 200 万行) にわたるレコードを含む 1000 万行のテーブルがあるとします。明確な年を取得したいと思います。標準のクエリとインデックスではこれを行うことはできませんが、WITH RECURSIVE CTE を構築して、本質的に毎年同じクエリを 1 回実行し、インデックスを使用することはできます。もちろん、その場合はインデックスを作成したほうがよいでしょう。そうしないと、WITH RECURSIVE が毎年のシーケンシャル スキャンを実行することになりますが、これは確かに望んでいるものではありません。

tl;dr: 複雑です。結論に飛びつく前に、これが本当に悪い計画であることを確認し、それが悪い計画である場合は、構成に応じて何ができるかを確認します。

于 2012-09-01T01:44:37.493 に答える