問題タブ [query-planner]

where句のすべての列にインデックスがあり、すべての列が結合されているにもかかわらず、実行に20分かかるクエリがあります。

これが私のクエリプランです。

私を困惑させることの 1 つはこれです: 次の WHERE 句を追加すると、クエリは約 0.5 秒で返されます。

well, duh, of course it gets much faster with thatつまり、ModelImport テーブルには 351 レコードしか含まれていないということです。つまり、上記のクエリを 351 個のクエリに分割し、それぞれに個別の ModelCode に対する独自の where 句を指定すると、クエリ結果の 100% を約 175 秒 (2.9 分) で取得できます。これは劇的に高速です。これは、広く開かれたクエリの何かが非常に非効率的であり、クエリ プランが悪いことを示しています。

これが追加された私のクエリプランです。AND mi.ModelCode = '3FBK5'

query planを表示した後、これを高速化する方法はありますか?

postgresql に奇妙な問題があります。プランナーは、外部キー インデックスを介したデータへのアクセスが非常に遅いと判断し、シーケンシャル スキャンを使用します。

単純化されたテーブル構造があります。

テーブルpassengerには約 1,400 万行、テーブル フライトには約 6 万行あります。

問題は、多くのオプション条件を含む QueryDSL クエリがあり、そのうちの 1 つが乗客をフライトでフィルタリングすることです。

そして、これらのオプションの条件に適合するすべての乗客を取得しようとすると、以下のようなクエリが生成され、30 秒間実行されます。それは恐ろしいです。passengerどういうわけか、すべてのテーブルに対して順次スキャンとハッシュ結合を使用します。

ただし、解決策を探して 1 日を過ごした後、flightテーブルの主キーを使用すると、postgres が主キー インデックスを使用することがわかりました。

残念ながら、手動で受け取った行をフィルター処理することはできません。これは、 が設定されている場合、1 フライトあたり約 300 人の乗客に対して、約 1,300 万行になるためflightIdです。

➥ それで、私の質問は次のとおりです: この条件に特定の列を使用するように QueryDSL/Hibernate に指示する方法はありますか? つまりflight.id、そうではありませんpassenger.flight_id。

または、別の質問: PostgreSQL プランナーの何が問題なのですか?どうすれば修正できますか?

UPDプランナーの計画:

• WHERE 条件で主キーを使用する適切なクエリ:

• WHERE 条件で外部キーを使用する不適切なクエリ:

次のような数百万のドキュメントのコレクションがあるとします。

{organization: 1} と {updated_on: 1} の両方のキーの 2 つのインデックス

次のクエリは、返されるまでに時間がかかります。

注意すべきことの 1 つは、結果が 0 件の一致であることです。さらに調査すると、explain() のプランナーは実際に次を返します。

• Mongo がこれらを 1 つのステージにまとめて、フィルタリングの前にすべてのドキュメントを並べ替えることにしたのはなぜですか?
• どうすればそれを防ぐことができますか?