등호 연산자와 LIKE 연산자 간 비교

얼마 전 SQL 쿼리를 작성하다가 문득 문자열 칼럼에 퍼센트(%) 기호없이 LIKE를 쓰는 것과 곧바로 등호 연산자를 쓰는 것에 어떤 차이가 있는지 의문이 생겼다.

다만 이를 곧바로 해결하지 않았다가 잊고 있었는데, 스터디를 위해 책을 읽다가 LIKE 연산자를 사용할 때와 등호 연산자를 사용할 때 내부적인 작동 방식이 차이가 있는 것으로 생각되어 이를 정리하고자 이 글을 작성한다.

해당 문서는 Mysql을 기준으로 작성되었으며, 다른 DB의 경우 다르게 작동할 여지가 있습니다.

 

 

LIKE vs Equal(=)

LIKE를 사용할 경우 와일드카드의 도움을 받아서 더 자유로운 방식의 문자열 비교가 가능하다는 것은 대부분이 아는 사실이니 넘어가도록 하자. (Equal에서는 와일드카드들도 전부 비교 문자열의 일부로 취급)

오직 해당 글에서 확인하기를 원하는 것은 와일드카드 없이 (ex. % 기호를 통한 부분 일치 여부 판단) Equal 연산을 수행할 때와 동일하게 LIKE를 사용했을 때 둘 간에 어떤 차이가 있는지이다.

해당 내용을 찾기 위해 구글링을 좀 해보았는데, 크게 도움이 되는 아티클은 없었던 것 같다.

(오히려 함정들이 많았다. 해외 쪽 아티클이라고 맹신하면 안될 듯)

그래서 결국 Mysql 공식 문서를 뒤적거렸는데, 거기에서 감을 잡을 수 있었다.

MySQL :: MySQL 8.0 Reference Manual :: 12.8.1 String Comparison Functions and Operators

공식문서의 설명

공식 문서에서는 LIKE 연산자가 문자 하나씩 비교하는 형태로 작동하고, 이로 인해 등호 연산자와는 완전히 다른 결과가 나올 수 있다고 이야기한다.

이와 함께 나오는 예시가 바로 아래의 형태인데, 처음엔 예시조차도 제대로 이해하지 못했다.

mysql> SELECT 'ä' LIKE 'ae' COLLATE latin1_german2_ci;
+-----------------------------------------+
| 'ä' LIKE 'ae' COLLATE latin1_german2_ci |
+-----------------------------------------+
|                                       0 |
+-----------------------------------------+
mysql> SELECT 'ä' = 'ae' COLLATE latin1_german2_ci;
+--------------------------------------+
| 'ä' = 'ae' COLLATE latin1_german2_ci |
+--------------------------------------+
|                                    1 |
+--------------------------------------+

이를 이해하기 위해서는 Mysql의 Character Set과 Collation에 대한 이해가 있어야 하는데, 위 예시를 기준으로 간단히 말하자면 latin1_german2_ci 로 불리는 Character Set에서는 기본적으로 ä와 ae를 동일시한다. 그렇기 때문에 문자열을 한번에 비교하는 등호 조건의 경우, 이를 정상적으로 동치 처리하지만 문자열 하나씩 확인하는 LIKE 연산자에서는 둘이 다르다는 결론이 도출되는 것이다.

 

 

실행 계획 비교

두 연산자의 작동 방식 차이가 실제 실행 계획 상에서는 어떻게 나타나는지 확인해보겠다.

이를 위해 아래와 같이 채워져 있는 COMMENT 테이블을 생성해주었다. (전체 데이터 수: 2,000,000개)

이제 content 칼럼을 통해 확인을 진행하겠다. 

Index 생성 칼럼

우선 인덱스가 걸려있을 때와 없을 때의 차이를 확인하기 위해 먼저 content 칼럼에 인덱스를 생성해주었다.

CREATE INDEX comment_index_for_test ON COMMENT (content);

Equal 조건 (Using Index)

등호 조건으로 검색한 결과이다.

테스트를 위해 생성해준 인덱스를 잘 탔고, 실제 스캔 로우 수가 1이기 때문에 비효율 없이 필요한 데이터만을 읽었다. 실행 계획 상에서 Index lookup이라는 표현이 있는데, 이는 동등 조건으로 인덱스를 검색했을 경우 나타나는 실행 계획이다.

Like 조건 (Using Index)

LIKE 조건으로 검색한 결과이다.

위와 마찬가지로 인덱스를 잘 활용했으나 이번엔 Index range scan이라는 표현이 나타났다. 이는 범위 탐색 조건으로 인덱스를 스캔할 경우 나타나는 실행 계획이며, 이를 통해 내부적으로 LIKE 연산자를 범위 탐색 연산자로 여기고 있음을 알 수 있다. 다만 단일 인덱스 구성이라 그런지 비효율은 크게 존재하지 않았다. (cost가 1에서 2로 증가하긴 했지만 체감될만한 결과는 아닌듯)

Index 사용시 비교 결과

두 경우 모두 인덱스를 잘 활용하는 모습이 보였다.

다만 등호 연산자와 다르게 LIKE의 경우 내부적으로 범위 탐색 연산자로 인지하는 것으로 보이는데, 이 경우 해당 칼럼이 단일 인덱스로 사용되거나 복합 인덱스의 최우측 칼럼으로 사용되는 것이 아니라면 인덱스 탐색 과정에서 비효율이 발생할 수 있다. (이는 인덱스 상에서 범위 탐색을 유발하는 칼럼 뒤로 나오는 칼럼들은 전부 인덱스 필터링 조건으로 사용되기 때문.)

 

일반 칼럼

이제 인덱스가 걸려있지 않은 칼럼을 이용한 실험을 위해, 생성해주었던 인덱스를 다시 삭제해주었다.

 ALTER TABLE COMMENT DROP INDEX comment_index_for_test;

Equal 조건 (Not Using Index)

실행 계획을 보면 데이터가 이백만개에 달하는 전체 테이블을 확인하면서 필터링 조건을 통해 조건을 만족하는 데이터를 찾은 것을 확인할 수 있다. (Table Full Scan)

이로 인해 Index를 활용할 때에 비해 cost가 이십만 단위로 치솟았다.

LIKE 조건 (Not Using Index)

실행 계획을 확인해보면 LIKE 조건일 때도 별반 다르지 않다. 결국 인덱스가 아닌 칼럼으로 필터링을 수행해야 하는 상황이고, 그렇기 때문에 동일하게 테이블 전체를 확인해야하는 상황이다. 

실행 계획의 cost 조차도 동일하다.

공식문서에서 LIKE 연산자는 문자 하나씩 비교하는 방식이라는 언급이 있었기 때문에 개인적으로는 이에 대한 부하도 체감이 될 것이라고 생각했는데 그렇지는 않은 모습.

문자 하나씩 비교하는 것에 대한 부하

이를 확인하기 위해 COMMENT 테이블에 칼럼 하나를 더 추가하고, X 문자열을 200번 반복하는 문자열로 데이터를 패딩해주었다.

 ALTER TABLE COMMENT ADD COLUMN tmp_content VARCHAR(255) DEFAULT '';
 
 UPDATE COMMENT SET tmp_content = CONCAT(content, REPEAT('X', 200));

그리고 등호 조건과 LIKE 조건을 각각 확인했다.

등호 조건

LIKE 조건

기존 content 칼럼에 문자열 길이 200의 문자열을 패딩해주었음에도 불구하고 두 실행 계획에서 큰 차이는 보이지 않는다. 

혹시나 문자열 순회를 앞에서부터 수행하고 다를 경우 early return 하는 로직을 대비하여 이번엔 패딩을 앞쪽에 해주고 다시 실행해보았다.

등호 조건(문자열 앞쪽 패딩)

LIKE 조건(문자열 앞쪽 패딩)

그러나 이경우 또한 마찬가지로 큰 차이가 없었다.

Index 미사용시  비교 결과

냉정하게 큰 차이가 없다고 보는게 맞을 것 같다.

특히 문자열의 길이가 길 때 LIKE 연산자가 한문자씩 비교하는 메커니즘이라는 공식 문서의 설명에 의해 차이가 나타날 것이라고 생각했으나 그렇지 않은 모습을 보인다. 아무래도 연산의 판단 기준이 그렇게 작동한다는 것이지, 연산의 시간복잡도가 차이난다는 의미는 아닌 것으로 생각된다.