첨부하신 플랜을 봐서는 인덱스 스캔은 되는 것으로 보입니다.

\"인덱스를 안탄다\"고 표현하신 것이 결과 튜플이 인덱스 키 순으로 정렬되지 않는다는 점을 말씀하신 것 같습니다.

큐브리드는 인덱스 스캔에서 얻어낸 튜플들을 접근할 때 locality of reference를 최대한 높이기 위해서 키 순서가 아니라 OID 순서로 정렬하여 접근합니다. 이에 따라서 결과가 키 순서로 정렬되지 않은 상태로 출력될 수 있습니다.

질의에 ordering 조건을 부여하면 질의 최적화기가 알아서 실제 order by 처리 없이 원하시는 데로 키 순서로 정렬된 결과를 생성합니다.

 

위 질의 기준으로 생각하면,

 

select * from cls_pam_gr_otcode

where artist_idx < 10000  and rownum between 1 and 10

order by artist_idx desc;

 

이와 같이 질의를 하시면 됩니다. 질의 최적화기가 인덱스 스캔 결과를 키 순서로 액세스하여 order by 절 처리를 무시하는 것이 효율적이라고 생각되면, order by 절 처리 없이 수행할 것입니다. 이 예에서는 reverse index가 사용되므로 descending 순으로 정렬했을 때 order by 절 처리가 무시될 수 있습니다. normal index의 경우에는 반대로 ascending 순일 때 이와 같이 최적화됩니다.

 

order by 절 없이 항상 키 순서로 인덱스 스캔 결과를 얻으려면, $CUBRID/admin/sqlx.init의 index_scan_order 파라미터를 1로 변경하시면 됩니다.

 

 

>Index를 안탑니다.

>

>Create Reverse Index i_cls_pam_gr_otcode_artist_idx on cls_pam_gr_otcode(artist_idx);

>

>

>

>select * from cls_pam_gr_otcode

>where artist_idx < 10000  and rownum between 1 and 10 using index i_cls_pam_gr_otcode_artist_idx(+)

>

>이러면 인덱스를 타서

>999

>998

>997

>....

>

>이런 형식으로 나와 하는데

>자기 멋대로 나오는 이유는 뭔지..

>

>Query plan:

>

>iscan

>    class: cls_pam_gr_otcode node[0]

>    index: i_cls_pam_gr_otcode_artist_idx term[1]

>    sargs: term[0]

>    cost:  fixed 0(0.0/0.0) var 0(0.0/0.0) card 27

>

>

>자료는 만건이 넘습니다.