[DB] MySQL Union에 대해서

프로젝트를 진행하면서 Union all을 사용하게 되면서 고찰하고 문제점을 개선한 이야기입니다.

 

---

Union All을 사용하게된 배경

해당 서비스는 혼자 여행할 때 포스트 게시와 여러 명이 동행을 하면서 포스트 게시하는 서비스로 포스트가 저장되는 테이블이 2개 존재했습니다. ( 혼자 할 때, 함께 할 때)

 

2개의 테이블에서 특정 시간 내에 사용자가 마지막에 게시한 포스트들을 조회해야 했습니다.

두 개의 서브 쿼리와 동행의 연관관계 때문에 여러 번의 조인문이 존재했습니다. 문제는 Union All이었습니다.

 

Union All을 사용하게 되면 두 개의 SELECT문이 하나로 합쳐지면서 인덱스를 타고 조회할 수 없게 됩니다. 데이터 량이 적으면 상관없겠지만 좋은 방법은 아닙니다. 또한 두개의 SELECT문을 메모리에 올려놓기 때문에 메모리적으로도 좋을 수 없습니다.

 

이때 MySQL의 저장 프로그램 Trigger를 사용해서 개선할 수 있습니다.

 

1. 조회할 테이블을 생성합니다.
2. 혼자 여행 포스트가 create 될 때 Trigger를 써서 테이블에 create 해줍니다.
3. 동행 여행 포스트가 create 될 때 Trigger를 써서 테이블에 create 해줍니다.

이때 중요한 것은 유저가 혼자 여행할 수도 있고 동행도 할 수 있다는 점입니다.

 

Trigger 문에는 ON DUPLICATE KEY 옵션이 있습니다.

 

Key 중복되었을 때 옵션을 설정할 수 있습니다.

 

위 쿼리를 자세히 보면 AFTER UPDATE ON을 확인할 수 있는데 왜 UPDATE이냐 INSERT가 아니냐는 의문을 가질 수 있습니다.

 

Spring Jpa에서 save 할 때 Hibernate 쿼리를 자세히 보면 insert문을 날릴 때도 있고 update문을 날릴 때도 있습니다.

 

이에 대한 이야기는 다음 포스트로 정리하겠습니다.

 

이렇게 두 개의 테이블을 지지고 볶던 쿼리가 SELECT문 하나도 만들 수 있었습니다.

 

Union All을 개선하는 방법은 상황에 따라 조건에 따라 다양합니다.

 

환경과 조건에 맞는 해결책을 고민해 봤던 시간이 되었습니다.