반응형

UNION의 실행 계획은 아주 단순하다. UNION으로 통합된 SELECT를 위에서부터 순서대로 실행해 나가면 된다. 단, Mysql 5.6까지는 UNION ALL의 경우에도 임시테이블을 작성하는 모양새였다.
UNION ALL은 중복을 배제하지 않기 떄문에 사실은 임시테이블을 작성할 필요가 전혀 없다.


Mysql 5.7에서는 이런 점을 개선하여 불필요하게 임시 테이블을 작성하지 않도록 했다. 한편, UNION DISTINCT의 경우에는 실행 계획에 포함된 각 행을 단숨에 처리해야 하기 때문에 임시 테이블을
이요하여 값의 중복을 배제했다. 이와같은 동작은 Mysql 5.7에서도 바뀌지 않았다.
-->temeporty table를 사용하지 않는 것만으로도 응답시간이 빨려졌고 성능개선이 되었다. 하지만 대용량 테이블 JOIN 시에는 UNION ALL의 개선을 크게 느낄 수는 없었다. 그냥 웬만하면 대용량테이블은 UNION ALL안에 두지 말자.

 

UNION은 SELECT를 순서대로 실행할 뿐이므로 상세한 해설은 생략하겠다. 한가지만 언급하자면, UNION을 사용한 쿼리의 성능은 각각의 SELECT에 좌우된다. 각각의 SELECT가 효율적이라면 UNION한 결과도 효율적이다.

UNION이 느린것 같다면 UNION에 문제가 있는 것이 아니라 열거된 SELECT 중 하나가 느릴 가능성이 높다.

 

단, 엄청나게 많은 select를 UNION에 열거하면 UNION 그 자체로 느려질 수 있다.
쿼리의 실행 시간은 대략 SELECT 수에 비례하여 길어지기 때문이다.

반응형
블로그 이미지

dung beetle

취미는 데이터 수집 직업은 MYSQL과 함께 일하는 DBA의 소소한 일상 이야기

,