1

データベースに巨大なログテーブルがあります。log_id と log_date にはインデックスがあります。

ログを逆の順序でクエリすると、完了するまでに「永遠に」かかります。注文なしで同じクエリを実行すると、答えはすぐにわかります。

どうすればテーブルを調整したり、クエリを改善して、より迅速な (より) 逆選択を行うことができますか?

編集：クエリ（申し訳ありませんが、クエリは私の頭の中で明白でした（そしてFlorinでも！）：

select * from logs ordered by log_date desc

いくつかの指標:

テーブルには約 4,000 万行あります

select * from logs where log_id < 500

--> 0.032 秒で取得 

select * from logs where log_id < 500 order by log_time desc;

--> 約 20 秒で取得

$max は最大 log_id であり、別のクエリで取得されています

select * from logs where log_id > ($max - 500);

--> 約 16 秒で取得 

select * from logs where log_id > ($max - 500) order by log_time desc;

--> 約 16 秒で取得

私の質問は、実行に時間がかかりすぎるすべてのクエリを改善する方法です。

@Florin
「where」句を使用してログを絞り込むと、(where log_time >= truncate(sysdate))パフォーマンスは良好ですが、長期間または過去の範囲のログを選択できる必要があります。この場合、クエリはまだかなり遅いです (20 秒など)。

4

1 に答える 1

3 
select * from log_table 
where log_date >= trunc(sysdate)  --current_day
order by log_id desc, log_date desc

これにより、log_date インデックスで範囲スキャンが実行され、テーブル全体ではなく、log_table から 1 日分の行が取得されます。この後、ソートする行が少ないため、ソートが高速になります。

更新： あなたができるもう一つのこと：

  • log_date 列を作成しますNOT NULL(これにより、オプティマイザーがインデックスを使用するように変更される場合があります)。
  • ヒントを使用して/*+parallel(logs 8)*/ください（このクエリを頻繁に実行せず、db ツールで結果をすばやく取得する必要がある場合。また、多くのプロセッサを使用している場合 :) ）
  • テーブルを月ごとに分割することも、さらに詳細に分割することもできます。
于 2012-06-14T05:43:21.147 に答える