or조건을 union all로 변경하는것에 관하여
abletech 수험생

답변 채택시 : 0코아

답변 2 추천 0 조회 3589 2014.08.20

안녕하세요?

한가지 궁금한것이 있어서 질문드리려 합니다.

 

a라는 테이블이 있고

aa,ab,ac라는 컬럼이 있습니다.

aa,ab,ac모두 각각 개별로 인덱스가 걸려 있습니다.

 

검색조건이

select * from a where aa=1 or ab=1 or ac=1

이라고 할때, index merge로 인덱스 검색이 되는것을 확인했습니다.

 

그런데 이것을 union으로 바꾸어서 실행계획을 보면

select * from a where aa=1

union all

select * from a where aa=2

union all

select * from a where aa=3

의 경우

index_ref로 3회실행되어 최종적으로 합쳐지는것으로 실행계획이 나옵니다.

 

어느것이 성능상 유리한지 알수가 없어,

질문드리고자 합니다.

 

좋은 가름침 부탁드립니다.

 

감사합니다.

 

답변글을 보고 추가 사항을 적습니다.

union all로 한것은 데이터가 중복되는 것이 없기 때문입니다.

unoin으로 하나 union all로 하나 같은 결과가 나오기 때문에

성능에 유리한 union all과 비교를 부탁드린것입니다.

 

처음부터 질문을 자세히 했어야 하는데, 죄송합니다.

댓글 (0)
목록 답변등록
or조건을 union all로 변경하는것에 관하여
lancelot 2014.09.11

앞의 답변은 두 쿼리의 WHERE 조건절이 첫 번째 쿼리는  aa, ab, ac 컬럼을 사용한 것에 반해, 두 번째 쿼리는  aa컬럼만 사용한 것이 다르고, 이것을 UNION으로 연결하지 않고 UNION ALL로 연결한 것에 대해서 쿼리상의 오류를 얘기한 듯하고요,
다시 질문하신 것 처럼, 질문의 요지는 INDEX MERGE와 UNION ALL의 성능상 잇점을 알려달라는 것으로 이해됩니다. 

 

먼저 INDEX MERGE와 UNION을 비교해야 할 듯하네요.
INDEX MERGE는 인덱스 컬럼과 ROWID로 작업하는, 행규모보다 상대적으로 적은 인덱스 레벨에서 수행하는 작업입니다.  UNION은 INDEX 작업 후 결과세트의 로우를 받아온 다음의 작업이죠.
각각의 값을 찾고 중복을 제거하는 작업이 인덱스 레벨에서 이루어 졌는지, 행레벨에서 이루어 졌는지가 중요합니다.

작업량의 차이때문이죠. 이 경우라면 INDEX MERGE가 유리하겠죠. 중복이 많다면 그 효과가 더 클 것입니다.

 

이 설명에서 느끼셨겠지만 INDEX MERGE는 행작업의 부하를 인덱스작업으로 처리하여 작업량을 감소시키고자 하는 것입니다. 

사실상  UNION ALL과는 비교대상이 아니지요.  

 

그런데, 굳이 UNION ALL과 비교하자면, UNION ALL은 중복을 제거하는 SORT-UNIQUE와 같은 작업을 수행하지 않으므로 각각의 인덱스 검색-->행반환-->UNION-ALL이라는 작업을 수행하게됩니다. 
인덱스 검색-->BITMAP 작업/ROWID 변환작업-->행반환 작업을 수행하는 것보다 효율적이겠지요.

데이터 량이 적은 경우 UNION-ALL의 부하가 더욱 적어지므로 UNION-ALL이 더욱 유리할 것입니다.

 

질문에 대한 답변은 여기까지고요, 혹시나 해서 한번 더 말씀드리면  해당 업무에서 OR로 연결된 조건이 완벽하게 EXCLUSIVE하다고 보증되지 않는다면 UNION-ALL 연산자를 사용하면 안됩니다.
성능은 데이터의 정확성을 100% 보증한 다음에 수행하는 MISSION이죠.

 

도움이 되셨기를 바랍니다.

댓글 (0)
or조건을 union all로 변경하는것에 관하여
stbo 2014.08.22

먼저 질문 자체에 문제가 있음을 알려드립니다. OR UNION ALL을 비교하셨는데 OR UNION ALL은 쿼리 결과값 자체가 틀립니다.  

이를테면, OR UNION의 개념입니다. 같은 로우이면 1건이 출력되나 UNION ALL 2건이 출력되므로 비교 자체가 되지 않습니다.

 

, 결과값이 다르므로 비교대상이 될 수 없습니다.

댓글 (0)