데이터베이스 질문과 답변
안녕하세요, 현아남푠입니다.
이제 막 DB를 배우기 시작한 초보인데 쿼리문 속도 향상에 관해 조언을 구하고자 합니다.
원하는 날짜( 시작날짜, 종료날짜 ) 를 선택하여 해당 날짜내의 데이터를 조회하기 위한 쿼리인데
해당 테이블의 총 데이터가 약 2백만건 정도 되구 조회 시간이 무지하게 오래 걸립니다.
아직 초보라 테이블 압축이나 파티셔닝은 모르구, 쿼리문 수정으로 속도를 향상 시키고자 합니다.
많은 도움 부탁드립니다..
[쿼리문]
select p.EQUIP_ID, to_char( p.ACQ_TIME, 'mm/dd hh24:mi:ss' ) ACQ_TIME , p.UL_ALLOC, p.UL_USE, p.UL_ERROR , p.DL_ALLOC, p.DL_USE, p.DL_ERROR , p.BROADCAST , e.EQUIP_NAME from TBL_DEV_HIST_RADIO p, TBL_EQUIPMENT_INFO e where e.EQUIP_ID = p.EQUIP_ID and p.DRILL_ID = 649 and ACQ_TIME between to_date( '2015-09-05 11:25:08', 'yyyy-mm-dd hh24:mi:ss' ) and to_date( '2015-10-07 11:30:08', 'yyyy-mm-dd hh24:mi:ss' ) order by e.EQUIP_NAME asc, p.ACQ_TIME asc
43162 rows selected.
execution time : 54 sec
[ 테이블 속성 ]
| Column Name | ID | PK | Index Pos | NULL? | Data Type |
|---|---|---|---|---|---|
| DRILL_ID | 1 | 1 | 1 | N | INTEGER |
| EQUIP_ID | 2 | 2 | 2 | N | CHAR(3) |
| ACQ_TIME | 3 | 3 | 3 | N | DATE |
| UL_ALLOC | 4 | Y | INTEGER | ||
| UL_USE | 5 | Y | INTEGER | ||
| UL_ERROR | 6 | Y | INTEGER | ||
| DL_ALLOC | 7 | Y | INTEGER | ||
| DL_USE | 8 | Y | INTEGER | ||
| DL_ERROR | 9 | Y | INTEGER | ||
| BROADCAST | 10 | Y | INTEGER |
테이블이 두개인데 속성은 하나만 주셨네요.
TBL_EQUIPMENT_INFO 테이블
| Column Name | ID | PK | Index Pos | NULL? | Data Type |
|---|---|---|---|---|---|
| EQUIP_ID | 1 | 1 | 1 | N | CHAR(3) |
| EQUIP_NAME | 2 | Y | VARCHAR2(64) | ||
| EQUIP_DESC | 3 | Y | VARCHAR2(128) | ||
| EQUIP_TYPE | 4 | N | CHAR(1) |
실행계획에 index를 타고 검색이 되는지 확인하셨는지요?
인덱스가 설정이 되어있는지가 관건인것 같네요
네.. 실행계획 실행해 봤는데 인덱스 설정되어서 실행되고 있었습니다.
실행계획 라인은 130줄 정도 생기구요..
단순 조인 쿼리인데?
실행계획이 130 라인이나 나온다구요?
네..ㅠ 같은 명령이 반복된거 같은데 마지막에 "130개의 행이 선택되었습니다." 라고 떴습니다..
근데 방금 다시 해보니 8 라인이네요..ㅠㅡㅜ 죄송합니다.. 실행계획은 다음과 같습니다.
Explain Plan
------------------------------------
SELECT STATEMENTcost estimate:8
SORT ORDER BY
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID:XXX,,,,,,,,TBL_DEV_HIST_RADIO(1)
INDEX RANGE SCAN:XXX,,,,,,,,,PK_TBL_DEV_HIST_RADIO
INDEX UNIQUE SCAN:XXX,,,,,,,,,PK_TBL_EQUIPMENT_INFO
TABLE ACCESS BY INDEX ROWID:XXX,,,,,,,,TBL_EQUIPMENT_INFO(2)
도움 부탁드려요 ㅠ
일단 인덱스는 정상적으로 탔네요.
하지만 인덱스 스캔 범위(drill_id = 649)가 최종 결과량(4만건)에 비해 너무 큰 듯 합니다.
tbl_dev_hist_radio 의 PK 3개 항목중 첫번째 항목만 인댁스 탐색을 하고
2번째 항목에 대한 조건이 없으므로 3번째 조건은 탐색조건이 아닌 필터조건이 되어 버립니다.
다음 4가지 사항이 성능에 영향을 주는 듯 한데요.
1. 인덱스 스캔 범위가 너무 크다
2. 4만건에 대한 테이블 랜덤엑세스
3. 4만건에 대한 NL 조인
4. 정렬에 대한 부담
이 중 어느 것이 가장 큰 영향을 미치는지..
한가지씩 쿼리에서 제거해 보면서 속도를 비교해 보세요.
drill_id = 649 에 해당하는 자료량이 얼마나 되나요?
tbl_equipment_info 의 전체 건수는?
tbl_equipment_info 의 전체 equip_id 의 Distinct Count 는 몇개인가요?
최최종 결과의 equip_id 의 Distinct Count 는 몇개인가요?
네 ㅠ 성의있는 답변 감사드립니다..
4가지 사항 참조하며 차근차근 한개씩 제거하며 시간재봐야 겠네요~~
drill_id = 649 에 해당하는 자료량이 얼마나 되나요? 30만건정도 됩니다.
tbl_equipment_info 의 전체 건수는? 장비 테이블이라 20건 밖에 되지않습니다.
tbl_equipment_info 의 전체 equip_id 의 Distinct Count 는 몇개인가요? ??
최최종 결과의 equip_id 의 Distinct Count 는 몇개인가요? ??
distinct count는 어디서 볼수 있나요?ㅠ 이건 잘 이해가 안가서 답변드리기 힘듭니다..
20건 밖에 안된다면?
2가지 방향으로 개선이 가능 할 듯 합니다.
위의 4가지 이슈중
3번. 4만건에 대한 NL 조인 부담을 줄이기 위해서 스칼라서브쿼리를 이용할 수 있습니다.
1번. 인덱스 스캔 범위를 줄이기 위해 테이블 엑세스 순서를 조정할 수 있습니다. /*+ LEADING(e) */
ㅠㅜ 답변 감사드립니다.
말씀해주신대로 수정해보겠습니다^3^
) 버튼을 클릭하여 작성 하시면 됩니다.