0

過去 10 日間からこのクエリのパフォーマンスを改善しようとしていますが、うまくいきません。主にorder by、クエリを実行したときにそれを削除すると数秒かかりましたが、order byが含まれている場合は5分以上かかるため、句の実行に時間がかかります。以下はクエリです-

Select a.user_vchr_char2, 
       a.voucher_id, 
       a.uap_clm_pymnt_stat, 
       a.pymnt_id_ref, 
       to_char(cast(a.lastupddttm as timestamp), 'YYYY-MM-DD-HH24.MI.SS.'),   
       to_char(a.pymnt_dt,'YYYY-MM-DD'),to_char(a.cancel_dt,'YYYY-MM-DD'),   
       to_char(a.scheduled_pay_dt,'YYYY-MM-DD'), to_char(a.transaction_date,'YYYY-MM-DD'),         
       a.descr254_mixed, 
       a.multiple_flg, 
       a.name1, a.name2, a.address1, a.address2, a.address3,     
       a.address4,a.city, a.state, a.postal, a.country, a.pymnt_method, a.gross_amt,  
       a.currency_pymnt 
FROM table_name a 
where  to_char(a.LASTUPDDTTM,'YYYY-MM-DD HH24:MI:SS') > :1 
order by a.user_vchr_char2, a.pymnt_cnt, a.uap_clm_pymnt_stat

indexで使用されている表に追加してみましorder byたが、改善は見られませんでした。誰でも助けてください。私はこの分野にまったく慣れていないので、簡単にしてください。

ありがとう！

4

3 に答える 3

0

I recommend you to use a temp table.

IF EXISTS(SELECT name FROM tempdb.sys.objects WHERE name='##temp_table')
BEGIN
    DROP TABLE ##temp_table
END

Select a.user_vchr_char2, a.voucher_id, a.uap_clm_pymnt_stat, a.pymnt_id_ref, to_char(cast(a.lastupddttm as timestamp), 'YYYY-MM-DD-HH24.MI.SS.'), to_char(a.pymnt_dt,'YYYY-MM-DD'),to_char(a.cancel_dt,'YYYY-MM-DD'), to_char(a.scheduled_pay_dt,'YYYY-MM-DD'), to_char(a.transaction_date,'YYYY-MM-DD'), a.descr254_mixed, a.multiple_flg, a.name1, a.name2, a.address1, a.address2, a.address3, a.address4,a.city, a.state, a.postal, a.country, a.pymnt_method, a.gross_amt, a.currency_pymnt
INTO ##temp_table
FROM table_name a 
where to_char(a.LASTUPDDTTM,'YYYY-MM-DD HH24:MI:SS') > 1

And then you can use order by clause like this.

SELECT *
FROM ##temp_table
order by a.user_vchr_char2, a.pymnt_cnt, a.uap_clm_pymnt_stat
于 2013-03-29T13:08:53.720 に答える
0

order by の問題とは関係ありませんが、where 句で関数を使用しないことでパフォーマンスを向上させることができます。これの代わりに：

where  to_char(a.LASTUPDDTTM,'YYYY-MM-DD HH24:MI:SS') > :1

これを行う方法を探します。

where a.LastUpdDtTm >= a start date
于 2013-03-29T13:30:09.290 に答える
0

まず、インデックスが関数ベースでない場合は使用されません。説明計画を実行すると、確認できます。

オラクルの関数ベースのインデックスは、このように指定されます。

create index foo on table_name(to_char(a.LASTUPDDTTM,'YYYY-MM-DD HH24:MI:SS'));

次に、非常に多くの文字編集機能があるため、インデックス構成テーブルを使用することをお勧めします。これにより、データがインデックスに移動されるため、行データをロードするために何度も検索する必要がなくなり、時間を節約できます。これは、オラクルで実行できる最速のインデックスです。

create table table_name(a int, b int, c varchar2(20 byte))organization index tablespace users   
pcthreshold 20 including a,b

ここで、create 句の末尾の a と b がインデックス列にマップされます。order by は内部ソートを行うため、テーブルが並列である場合、これは大ヒットです。一般的なインデックス追加のパフォーマンスの大きさを取得する代替手段

parallel 4 (or how many parallel index queries you want)

例

create index foo on table_Name(to_char(a.LASTUPDDTTM,'YYYY-MM-DD HH24:MI:SS')) parallel 4

グローバル索引が使用されている場合、パーティショニングは役立ちますが、遅くなることに注意してください。これは、大量の行 (例: 10,000,000 行) を持つテーブルにのみ使用されます。テーブルに 100 万行あると、Oracle のパフォーマンスが低下します。テーブルに何行あるかわかりません。

于 2013-03-29T19:07:52.133 に答える