안녕하세요,
서비스를 운영하다보면 시간이 지날수록 여러가지 상황이 발생하게 됩니다.
정상적으로 잘 작동했던 쿼리가 시간이 지날수록 느려지는 경우도 있구요. 서비스를 관리하다가 이상현상(?)으로 Index가 제대로 적용이 안된 경우도 있었고(서버를 이전하다가 그런 경험을 한 적이 있습니다), 그 외에도 예측 못하는 다양한 경우가 있었습니다.
그래서 몇가지 쿼리 조회를 빠르게 수행하는 방법을 소개하려고 합니다.
느린 쿼리를 Explain 을 통해 조회하세요.
expain은 쿼리를 수행하기 전에 데이터를 어떤식으로 가져올 것인지에 대한 실행 계획을 나타내는 키워드입니다.
사용은 아래와 같이 수행하면 됩니다.
EXPLAIN SELECT * FROM BOARD WHERE BOARD_ID = ?위와 같은 형태로 Explain 을 통해 쿼리에 대한 기대를 조회할 수 있습니다.
Explain에 대한 설명은 다른 좋은 블로그 글이 있으니 참고하시구요.
중요한 것은 쿼리 조회에서 BTREE를 타는 것입니다. B-TREE를 타야 쿼리 조회 속도에 일관성을 유지할 수 있다는 점을 알아두셔야 합니다.
쿼리에 일관적인 속도를 유지하기 위해 되도록 NOT 키워드는 코드에 사용하지 마세요.
쿼리에 일관성을 유지하려면 NOT 키워드나 != 같은 것은 자제하셔야 합니다.
왜냐하면 저런 코드를 사용하게 되면 쿼리가 B-TREE를 타지 못하고 FULL SCAN이 날 수 있습니다(느려집니다).
그리고 경우에 따라선 예측하지 못한 결과를 낼 수도 있기 때문에 NOT 키워드를 사용을 최대한 자제하세요. JOIN으로 해결하세요.
IN 키워드보다는 EXISTS 키워드를 사용하세요.
검색 속도가 중요합니다. 더 빠른 속도를 위해 In을 사용하는 것 보다는 Exists를 사용하셔야 합니다. In은 row값의 전체를 비교하는데에 비해 Exists는 결과를 True/False 로 구하기 때문에 훨씬 더 빠르게 결과값을 얻으실 수 있습니다.
검색할 범위가 너무 많다면 나눠서 검색하는 전략을 취하세요.
검색 범위가 너무 많다면 나눠서 검색하는 것도 좋은 방법입니다. 제가 혼자 작게나마 운영하고 있는 서비스는 지금 120만개 이상의 데이터를 가지고 있습니다. 검색할 범위가 너무 많다면 이를 쪼개는 방법도 좋은 전략입니다. 20만개씩만 쪼개어 검색하더라도 검색에서 많은 이점을 볼 수 있어요.
SELECT ENDPOINT FROM REDIRECTS WHERE 게시물 넘버(PK) > 일정 개수 and ~~~ # 이런 형태로 하시면 됩니다.위와 같은 형태로 검색하시면 아마 정말 빠르게 검색하실 수 있을거에요. 다만 위의 예제처럼 일반적인 게시판 기준 게시물id(PK)를 가장 먼저 잡아주셔야 합니다. SQL에서는 Where 절에서의 순서도 매우 중요하기 때문이죠!
정리: 고민, 고민, 고민,..
이런 글을 적을까 말까 고민을 수차례 했습니다. 저야 직접 경험한 일이긴 하지만 제 의견이 꼭 정답은 아니기 때문이죠. (쿼리 캐시도 있을 수 있으니까요)
이전에 제가 데이터센터에서 일할 때 특정 서비스의 로그인 기능을 오직 쿼리 튜닝만으로 10초에서 0초대로 낮추는 것을 목격한 적이 있습니다. 규모를 늘리기보다는 그런 수를 써서 장비 도입 비용 + 수 천만원의 라이선스 비용을 절감하는 것을 보고 (엔지니어 비용만 들었습니다.. 엔지니어 섭외도 깜짝 놀랄 비용이지만 장비 도입보다는 수십배를 아낄 수 있지요) 느낄 수 있었어요.
쿼리를 튜닝하는 것은 책장을 잘 정리하는 것과 같다고 생각합니다. 어깨너머로 주워듣고 몇 번 해보면서 알게된 아주 얕은 지식이지만 제 경험이 다른 분들에게 좋은 아이디어로 다가왔으면 좋겠습니다.
읽어주셔서 감사합니다 : )
