DB 인덱스는 만능일까?

 

프로젝트를 진행하면서 엔티티를 삭제할 때 실제로 레코드가 삭제되는 물리 삭제 방식이 아닌 삭제 플래그를 활성화하는 논리 삭제를 도입했다. 때문에 어떤 엔티티를 조회할 일이 있으면 WHERE절에 is_deleted=FALSE 조건을 항상 추가해줘야했다. 

 

그런데 자주 사용하는 칼럼에 인덱스를 적용하면 쿼리 성능이 좋아진다는 것을 듣고 실험을 해보았다.

먼저 더미 카드 데이터를 100만개 만들고,

 

내가 지금 만든 서비스에서 날리는 쿼리문을 50회씩 각각 날려보면서 평균 실행시간을 측정했다.

SELECT c.card_id, c.title, COUNT(DISTINCT m.id) AS manager_count
FROM card c
LEFT JOIN manager m ON m.card_id = c.card_id AND m.is_deleted = false
WHERE c.is_deleted = false
  AND c.title = '카드 추가'
GROUP BY c.card_id
ORDER BY c.card_id DESC;

 

이런 쿼리문을 is_deleted 컬럼에 인덱스를 적용하기 전, 적용한 후를 비교했을 때, 

 

적용 전 : 평균 83ms, 적용 후 : 평균 1459ms 성능 상승률 : 숫자로만 비교해봐도 대략 -1757%

 

왜 이런 일이 발생했을까? 

 

먼저 이를 알기 위해서는 

카디널리티, 선택도, B+트리 구조를 알아야 한다고 한다. 

 

카디널리티

:어떤 데이터 집합에서 유니크한 값을 가지는 레코드 개수 

 

선택도

:카디널리티/총 레코드 개수

 

즉 선택도는 어떤 데이터 집합에서 특정한 데이터를 얼마나 더 잘 찾느냐를 나타내는 지표인 셈이다. 

 

B+트리 구조는 이해가 잘 되게 정리된 블로그 글 링크 

https://velog.io/@emplam27/%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0-%EA%B7%B8%EB%A6%BC%EC%9C%BC%EB%A1%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-B-Plus-Tree

[자료구조] 그림으로 알아보는 B+Tree

 

여하튼 MySQL에서 인덱스는 B+Tree 구조를 이용하는데, 그렇기 때문에 선택도가 높은 컬럼에 인덱스를 걸어줬을 때 효율이 좋다고 한다 그런데 is_deleted는 값이 true, false 밖에 없기 때문에 선택도가 낮아서 오히려 인덱스를 걸어주면 성능 저하가 오는 것이다. 

 

앞으로는 이런 선택도를 생각해서 인덱스를 적용한 컬럼을 정해야겠다.