問題タブ [query-planner]

以下は、 explain.depesz.comの計画例です。

これらの操作はどのような順序で実行されますか? 一気飲み？トップダウン？

MS SQL Server クエリ プランナーが、OR 条件を使用した JOIN のユニオンを選択するのではなく、入れ子になったループを作成するのはなぜでしょうか。

注：SOで検索すると、MSSQL固有ではないようです

例えば

私の場合は6分かかります（OneとTwoの両方が両方のテーブルでインデックス化されています）

しかし

2秒かかります。

最初の処理に時間がかかる理由はわかっていますが (2 つのユニオンがインデックスを使用する入れ子になったループのため)、クエリ プランナーが UNION を実行プランとして選択しないのはなぜでしょうか?

UNION を使用していない UNION を使用する場合に注意する必要がある警告はありますか?

このロジックがクエリ プランナーに実装されていないのはなぜですか?

クエリプランナーのコードをよりシンプルに保つためだけですか (おそらくすでにかなり複雑なので)、最適化に取り組まなかったのですか、それとも私が気付いていない他の警告があるためですか?

2 つのクエリがあります。

そしてもう1つと同じJOIN：

これらのクエリは Django ORM によって生成されました。最初のものは 3 ミリ秒かかり、2 番目のものは 120 秒 (!) かかります。私はしましたVACUUM ANALYZE。以下EXPLAIN ANALYZEを与える：

• 最初のクエリ: http://explain.depesz.com/s/Eqy
• 2 番目のクエリ: http://explain.depesz.com/s/1ZTB

クエリ プランナーがこのようになった原因は何ですか? 2 番目のクエリでインデックスが使用されないのはなぜですか?

ハッシュを無効にしようとしましたが、より複雑な方法が使用されました。

編集：

インデックスの詳細:

私のテーブルには整数列「a」、「b」があります。"a" の異なる値はわずか (<30) ですが、各 "a" には膨大な数の異なる "b" が存在します (>10**7)。スピードアップするために、複合インデックス (a,b) を作成しました。私はそれを観察します

速く走る

速く走るが、

実行が (なんてこった) 遅く、同じことが次の場合にも当てはまります

説明を実行すると、高速クエリが使用することが説明されます

ただし、遅いクエリの場合は、シーケンシャル スキャンが使用されます。

これはなぜですか？Postgresql が後の 2 つのクエリに同じインデックスを使用しないのはなぜですか? クエリ プランナーの不完全性だけですか、それともインデックス オンリー スキャンを使用できないより深刻な理由がありますか?

バージョン 3.7.8 では、クエリ プランは次のようになりました。

しかし、3.8.10.2では

変化したこと？推定行数を再度表示するように設定できますか?

制限数が異なる次のクエリでは、異なるクエリ プランと非常に異なるスキャン行が作成されます。

インデックスを持つテーブル:

異なる制限 (50 対 500) が異なるクエリ プランを作成し、スキャン行に大きな変化があるのはなぜですか?</p>

次のようなストアド プロシージャを SQL Server で実行しています。

これは、日付列のインデックスを無視しています。選択クエリを実行します。パラメーターを使用しても問題ありません。これに変更しても問題ありません。

クエリ全体を動的 SQL に変更したところ、問題なく動作するようになりました。

ここで何が起きてるの？

IN 句に 10 個のパラメーターを指定してクエリを実行し、次に同じクエリを 20 個のパラメーターを使用して再度実行する場合、データベース サーバーは最初の実行から実行プランを再利用できますか、または毎回作成する必要がある新しい実行プランです。時間？