database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
ㆍOracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Oracle Q&A 40095 게시물 읽기
No. 40095
[재질문] index_desc 힌트의 반대 정렬 경우
작성자
김지호
작성일
2013-04-12 10:07
조회수
7,220

몇일 전에 질문 드렸는데. 다시 한번 드립니다.

쿼리 1 >

select /*+index_desc( t_event  i_event_alarmtime)*/

rownum rnum, seq_no 

from t_event

where ((user_id in  (select user_id from t_user where user_no = 1163))

 

     and alarm_time between to_date('2013-03-27 00:00:00','yyyy-mm-dd hh24:mi:ss')

쿼리 2>

select /*+index_desc( t_event  i_event_alarmtime)*/

rownum rnum, seq_no 

from t_event

where ((user_id in  (select user_id from t_user where user_no = 1163))

     and user_id not in (select user_id from t_deleted_user  where status = 1 ) )

     and alarm_time between to_date('2013-03-27 00:00:00','yyyy-mm-dd hh24:mi:ss')

---------------------------

인덱스 i_event_alarmtime  은  ALL_IND_COLUMNS 테이블에서 확인 해보니 ,DESCEND 타입이 asc 속성을 만들어져 있네요.

쿼리 1은 alarm_time 값으로 내림차순(desc)으로 정상 잘 나옵니다. 

그런데, 쿼리 2 에서 where 조건절에 subquery 조건이 하나 더 들어가면(파란색) 결과가 오름차순(asc)으로 나와서

전혀 반대방향으로 나와버리네요.

 

서브쿼리가 영향을 주는 것인가요 ? 준다면 어떻게 된 사연일까요 ?

 

아래는 실행계획입니다---------

쿼리 1> 

 

| Id  | Operation                           | Name                         | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |

------------------------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT                    |                              |       |       |   355 (100)|          |       |       |

|   1 |  COUNT                              |                              |       |       |            |          |       |       |

|*  2 |   TABLE ACCESS BY GLOBAL INDEX ROWID| T_EVENT           |    15 |   345 |   355   (1)| 00:00:05 | ROW L | ROW L |

|*  3 |    INDEX RANGE SCAN DESCENDING      | I_EVENT_ALARMTIME | 19532 |       |    60   (2)| 00:00:01 |       |       |

------------------------------------------------------------------------------------------------------------------------------------

쿼리 2>

 

| Id  | Operation                            | Name                         | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |

-------------------------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT                     |                              |       |       |   360 (100)|          |       |       |

|   1 |  COUNT                               |                              |       |       |            |          |       |       |

|*  2 |   HASH JOIN ANTI                     |                              |     1 |    49 |   360   (1)| 00:00:05 |       |       |

|*  3 |    TABLE ACCESS BY GLOBAL INDEX ROWID| T_EVENTS           |    15 |   345 |   355   (1)| 00:00:05 | ROW L | ROW L |

|*  4 |     INDEX RANGE SCAN DESCENDING      | I_EVENT_ALARMTIME | 19532 |       |    60   (2)| 00:00:01 |       |       |

|*  5 |    TABLE ACCESS FULL                 | T_DELETED_USER     |     1 |    26 |     5   (0)| 00:00:01 |       |       |

-------------------------------------------------------------------------------------------------------------------------------------

 

이 글에 대한 댓글이 총 1건 있습니다.

몇일전에도 답변 드렸었죠.조인 방식에 따라 정렬이 흐트러 질 수 있다고.
Hash Join Anti 방식으로 조인되면서 정렬이 흐트러졌네요.


인덱스 역순으로 스캔하면서
스캔된 전체자료를 rownum 으로 일부만 취할때 효과가 있습니다.
그런데 이 경우는 스캔된 전체자료에 추가조건이 들어가네요.
user_id 에 대한 In 조건과 Not In 조건은 스캔 결과를 다시 또 걸러내는 조건입니다.
인덱스로 가져온 자료중 user_id 조건을 만족하는 극히 일부 자료만 취하게 되겠지요.
인덱스에 날짜 컬럼 외에 user_id 컬럼이 없다면
불필요한 랜덤엑세스가 많이 발생되게 됩니다.

다시 말하면 인덱스 스캔이 오히려 해가 될수도 있다는 것입니다.


Not In 은 성능저하의 주범이었는데..
이를 개선한 것이 Hash Join Anti 입니다.
성능을 개선하기 위한 옵티마이져의 노력입니다.


일단 ORDER BY 구문 추가하세요.
그리고 실행계획 확인하세요.

마농(manon94)님이 2013-04-12 11:02에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
40098오라클설치관련 [1]
개발자
2013-04-15
5825
40097HashMap 과 List 차이가 뭔가요? [1]
김기운
2013-04-15
5695
40096CASE WHEN 문에 대해 [2]
도움이 필요해요
2013-04-15
6647
40095[재질문] index_desc 힌트의 반대 정렬 경우 [1]
김지호
2013-04-12
7220
40093DB연결이 자주 끊기는 현상
한상원
2013-04-10
7033
40092파티셔닝 테이블에서 index_desc 처리 [2]
김지호
2013-04-09
6532
40091sqlplus 계정 <VIEW.sql 실행 시 [1]
소태섭
2013-04-05
6248
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다