최근 테이블 업데이트 과정에서 시간단축을 위해서 벌크 쿼리를 사용한 적이 있다. 그 과정에서 String 으로 구성된 컬럼 하나에 like 를 조건으로 사용해 시간결과를 확인해보았고 도저히 받아들일 수 없는 결과를 맞이했다.
벌크 연산 쿼리가 Querydsl 보다 훨씬 더 느린 결과가 나온것이다.
왜지?!, 바로 사수 개발자 분께 물어보니 쿼리를 보고 바로 문제를 짚어주셨다.
"LIKE 연산을 수행하네요, = 로 변경하세요"
1차 의문
LIKE 와 = 의 연산 알고리즘은 다른 방식인가?
LIKE 문은 %와 같이 사용하지 않는다면 결과적으로 동일한 문자열을 서칭하게 되는데 이것은 = 문의 사용과 동일한 결과 값을 보내준다. 실제로 둘의 알고리즘이 동작하는 차이를 알아보자 했고 하루동안 계속 찾아본 결과
DB에서 실제로 동작하는 LIKE 와 = 의 알고리즘은 확인할 수 없었다.
다만 확인 가능한것은 실제 쿼리를 날려 다양한 비용 이슈를 확인할 수 있다는것 이었는데 그 결과 LIKE 와 = 의 모든 연산 비용은 동일하다는 것을 알 수 있었다.
쿼리 1 의 결과 값은 = 을 이용하여 비용을 확인해본 결과이다.
쿼리 2의 결과 값은 LIKE 를 이용한 결과이다.
이상하게도 둘의 자원 비용이 완전하게 일치한다. 구글을 돌아다니다 보면 like 와 = 의 알고리즘에 대해서는 나와 있지는 않지만 몇몇의 블로그에서 더 빠르다는 이유로 = 사용을 권장한다고 한다. 그런데 실제로 사용해보니 같은 결과를 보여준다. 조인을 이용한 쿼리도 같은 실행 결과를 보여주는것을 보면 아무래도 둘의 알고리즘 방식이 차이가 있는것 같지는 않다. 그럼 왜 벌크 쿼리에선는 = 을 사용했을 경우 시간 단축이 발생했을까?
2차 의문
알고리즘이 동일하게 진행된다면 대체 왜 쿼리의 시간차이가 발생하는것이지?
답은 벌크 쿼리의 문제도 아니고 알고리즘의 차이도 아닌 바로 컬럼에 인덱스가 걸려있지의 여부였다.
벌크 연산을 통한 쿼리에서는 where 조건절로 인덱스가 걸린 컬럼을 조건으로 쿼리를 날렸다. 그렇기 때문에 LIKE 연산보다 = 연산에서 속도가 빠른것이었다.
실제로 인덱스에 걸린 컬럼으로 조회를 해볼 경우 아래와 같은 결과 차이를 얻을 수 있다.
쿼리 비용이 12% 감소하면서 실제로 더 빠른연산 속도를 보여줬다. 알고리즘은 알 수 없으나 실제로 인덱스 컬럼일 경우 LIKE 연산보다 = 연산이 더 적은 비용을 발생시킨다.
결론.
모든 데이터 베이스가 동일한 알고리즘을 통해 sql 연산을 하는것은 아니기 때문에 위와 같은 결과가 항상 보장된다는 얘기는 할 수 없다. 또한 인덱스에 걸려있지 않은 컬럼을 조회 할 경우에는 = 과 LIKE 의 성능차이가 크게 발생하지 않는다는 현상 분석이 있지만 이 또한 모든 경우에 있어서 다 적용된다고 얘기 할 수 없다. 하지만 인덱스가 걸린 컬럼에서는 성능 향상이 확실히 눈에 띄었기 때문에 eqaul 을 조건으로 사용하는 쿼리문에는 = 사용을 권장하는 것이 바람직하다는 생각이 든다.
