7

98w 行のデータがあります。pub_time でデータをソートしたいときに、興味深いものを見つけました。

SQLは次のとおりです。

select * 
from t_p_blog_article_info t  
order by t.pub_time desc

19秒かかりました。

select * 
from t_p_blog_article_info t 
where t.pub_time > to_date( '1900-01-01 01:00:00', 'yyyy-mm-dd   hh24:mi:ss ')  
order by t.pub_time desc

0.2秒かかりました。

知りたいのですが、なぜですか？

4

2 に答える 2

4

テーブルの pub_time にインデックスがある可能性があります。

したがって、2 番目のクエリはこのインデックスを使用して、指定された日付以降の null 以外の日付を持つレコードのみを返すことができますが、最初のクエリはテーブル全体をクエリする必要があります。

于 2012-03-13T13:14:27.253 に答える
0

さまざまな可能性があります。pub_time で無効/null の日付を含む多数の行を除外することはできますが、これらのかなりの数に気付かない/言及しないとは思えません。

心に残ったのは以下の3点です。

1 - pub_time を含むインデックスまたは複合インデックスがあり、where 句の制限により別のアクセス パスの使用がトリガーされている

2 - 最初のクエリを実行したとき、オプティマイザーで使用できる統計がありませんでした。2 番目のクエリを実行すると、最初のクエリを実行したときに発生した情報キャッシュのおかげで、より適切なアクセス パスが選択されました。これは、最初のクエリをさらに数回実行し、パフォーマンスが大幅に向上するかどうかを確認することで確認できます。

3 - 最初のポイントと同様に、オプティマイザは、where 句の意味のみに基づいて、より適切なアクセス パスを選択することができます。おそらく、null/無効な値を処理する必要がないというヒントを与えるだけで十分です。無効/null pub_times を除外するために、システムが 1 回以上のフル テーブル スキャンを回避している可能性があります。

このようなことの理由を特定することは、急速に経験的な冒険になりつつあります.プラットフォームとバージョンを知らなければ、これ以上言うことはできません. タグから、オラクルを使用していると思います。その場合、何らかの形式の「クエリの説明」または「計画の説明」ツールを使用して、何が起こっているのかをよりよく理解できるはずです。Oracle オプティマイザの詳細については、http: //docs.oracle.com/cd/B10500_01/server.920/a96533/optimops.htm を参照してください (これは Oracle 9i v9.2 用ですが、バージョンの適切な説明があります-独立した概念)

于 2012-03-13T13:46:30.187 に答える