데이터베이스 질문과 답변
by 아발란체 [2018.08.02 11:29:12]
아래 처럼 복합키를 만드는 것이 그리 좋은 방법이 아니라는 설명이 있습니다.
IX01 : ORG_ID + GRP_ID + STRD_ID + STC_DC
그 외 주어진 유일한 단서인 SQL 구문은 아래와 같습니다.
SELECT * FROM PRA_HST_STC A, ODM_RMS B WHERE A.ORG_ID = :ORG_ID AND B.GRP_ID = A.GRP_ID AND B.STRD_ID = A.STRD_ID AND B.TRMS_DT = :TRMS_DT ORDER BY A.STC_DT DESC
전 모르겠습니다. 주어진 단서만으로 저 복합키가 무엇이 문제인지.. ㅠㅠ
많은 가르침 부탁드립니다.
고맙습니다!
저라면
IX01 : GRP_ID + STRD_ID
IX02 : ORG_ID
INDEX를 따로 생성하겠습니다.
ORDER BY 느리면 STC_DT 추가로 생성할거 같아요.
IX02 생성해서 드라이브 테이블 범위를 줄이고
IX01 이 양쪽 테이블 JOIN시 사용되겠네요.
너무 구닥다리인가요? ㅎㅎㅎ
아 그리고 ORG_ID 는 어떤게 쓰일지 모르는데
결합인덱스 선두 컬럼으로 쓰긴 좀 위험하지 않을까해서 분리했습니다.
아니요 저도 다양한 관점으로 이해하고 해석하고 시도 할 것 같은데
조인에 대한 이해가 충분하다면 저 단서만 가지고 복합키 성능을 판단할 수 있다는게 전 실제 아는 것도 없지만 정답을 찾을 수가 없어서요.
조시형쌤에게 또 질문 올려봐야겠네용. 일면식도 없이 전화로도/카페로도/이메일로도 계속 물어보고 있어 좀 부끄럽지만 ㅠㅠ 모르던 부분을 너무 많이 배우고 있네요.
말씀 감사드립니다.
일단 정보가 너무 적어요.
저도 인덱스 해봤다 잘안되서 바꾸는 경우가 태반이에요.
기본 PK 빼고는 정말 많이 바꾸게 됩니다.
해당인덱스가 A쪽이예요? A쪽이면 범위를 한정할 수 있는 건 ORG_ID밖에 없게 되고.. 조인 후에 TRMS_DT로 필터.. 혹은 반대로 B쪽에 TRMS_DT가 선택도가 더 나았다면 TRMS_DT 인덱스를 만들고 B부터 탐색.. 책을 안 사서 정확히 무슨 내용인지 모르겠네요.
아.. 넵 A쪽입니다.
저라면 ORG_ID + STC_DT 로만 만들었을듯합니다.
나머지 컬럼은 별 의미 없고 오히려 중간에 끼어 있어서 STC_DT 정렬에 방해만 됩니다.
복합키인데 선두 컬럼만 인덱스를 탄다면 복합키 만들 이유가 없는 것 같은데..
A.GRP_ID와 A.STRD_ID도 인덱스 구성 항목으로 있으면
필터링 되지 않고 인덱스로 같이 타는게 유리하지 않은가용? @.@)/
정렬이 .. 아찌님 말씀처럼 문제 여지가 있는 것 같고용..
위의 쿼리만 보면
A 테이블 GRP_ID + STRD_ID 인덱스는 필요없었넹...
어짜피 A테이블은 ORG_ID 만 가지고 필터링해서 JOIN 할테니..
B. 테이블만 GRP_ID + STRD_ID + TRMS_DT 이 필요하넹
아..근데 돌려봐야지 알겠당.. ㅎㅎ
ORD_ID + STC_DT로 복합키 생성해놓으면 ORD_ID로 조회하면 STC_DT로 정렬되어있을 거라.. 정렬 부하가 줄어들거라는 예상입니다만.. 잘 될지는.. 해봐야 알겠죠? GRP_ID와 STRD_ID는 선행테이블에 데이터 범위를 줄여주는데 사용하지 않기 때문에 필요 없을 것 같고요. 오히려 결합 인덱스 중간에 끼어있어서 STC_DT의 정렬을 불가하게 만들어서 빼버리는 게 나을 것 같다는 판단입니다.
내용 원문 올립니다.
짤려 보여요..
내용은 다 들어 있습니다.
272페이지 짤린 부분 없이 273페이지 이어서 나오고 있습니다.
다운받아서 보니 다 보이네요..
A 테이블 : ORG_ID + STC_DT
B 테이블 : 선택도를 알 수 없으니 결합인덱스 구성 순서는 쿼리만 보아서는 알기 힘들고.. STRD_GRP_ID, STRD_ID, TRMS_DT 구성으로 결합인덱스 생성하겠습니다.
일단 틀리더라도 결론을 낸다면
NL 특성상 INNER쪽은 당연히 인덱스가 있다고 가정하고 풀이를 한다면
인덱스는 ORG_ID 1개로만 만들고
정렬도 인덱스 별도로 1개를 만들어 하는 것으로 이해가 됩니다.
ORG_ID + STC_DT 으로 인덱스 만들자니
정렬구문이 ORG_ID + STC_DT가 아닌
STR_DT 1개입니다. 선행 항목 빼고 INDEX_SS로 접근하는 것이 아닌 1개를 인덱스 따로 잡아도 될 것 같습니다.
한편으로는 A테이블쪽에서 4개 속성으로 다 만들어도 DML 부하나 스토리지 비효율은 있지만 역시 조회 비효율은 잘 보이지 않습니다. ㅠㅠ
조회 조건으로 ORG_ID 하나가 들어가니 ORG_ID + STR_DT 인덱스 하나면 될 것 같은데요.
넹 그것도 좋은데 따로 잡아도 좋을 것 같다고 쓴 부분입니다.
실측해보니 조회는 저것도 좋을 것 같아서요.
조회 인덱스와 정렬 인덱스를 따로 만드는 건 거의 본 적이 없는데.. 그게 더 효율적인가요? 음.. 나중에 테스트를 해봐야할 것 같습니다.
책에서 나오는 결합인덱스 효율 문제에서 말하려고 했던 것은
실제 탐색 범위에 영향을 주지 않는 컬럼을 결합인덱스에서 제거하고
ORDER BY 에서 사용하는 컬럼을 탐색조건 컬럼 바로 뒤에 오게 하므로써
인덱스만으로 정렬을 하는 게 효율적이라는 것을 말하려고 했던 것으로 보입니다.
인덱스만 믿고 ORDER BY절을 생략하면 11g nlj_batch 때문에 ORDER BY가 안 될 수도 있다고
설명한 부분도 그런 맥락에서 설명한 것으로 보이구요.
SQLP에서 수도 없이 나와서 저도 당연하게 생각하고 있는 부분인데..
플랜 다양성 보며 정신줄 놓고 있습니다. 시험용이 아닌 정말 성능 위주로 보고 있는데 저는 제대로 개념이 없어서 매우 혼란스러운 상황입니다.
근데 질문있습니다.
12c에서 건수가 적어 그런가 힌트 주지 않으면 해쉬조인 타는데 그래서 nl 힌트 주면
배치 i/o를 탑니다. 그래서 NO_NLJ_BATCHING 힌트를 주면.. 이눔이 PREFETCH를 탑니다. ㅡㅡ;;
그래서 또 NO_NLJ_PREFETCH 힌트를 주면.. 이눔이 멘붕이 오는 것인지 한쪽 힌트를 무시합니다. 물론 저의 무지겠지만.. 아무튼 전통적인 실행계획을 못보고 있습니다. ㅠ ㅠ 갈켜주세요.
아 그러고 보니.. 실측 뜨다 복합키 신뢰보다 정렬키 하나 더 만든다고 했는데....
근본적 문제는 이눔 12c가 자꾸 배치로 등록하여 order by절이 깨지는게 문제네요.
실행계획은 문제가 없는데 실측은 자꾸 프리패치랑 배치i/o가 올라오거든영... 아 삽질했다.. 이눔부터 처리를 해야겠네요.
) 버튼을 클릭하여 작성 하시면 됩니다.