[IT 도서 리뷰] Real MySQL 8.0 1권 (저자: 백은빈, 이성욱)
Real MySQL 8.0 1권 (저자: 백은빈, 이성욱)
책 추천
DB에 대해서 정말 깊이 배울 수 있는 책이다. 서비스가 커지고 서버에 트래픽이 늘어나고 데이터가 많아지면 제일 먼저 병목이 걸릴만한 곳은 DB이다. DB는 테이블 설계, 인덱스, 트랜잭션, DB 스토리지 엔진, 실행 엔진 버전 등에 따라서 많은 성능 차이를 보인다. 이 책에서는 MySQL 8.0에 대한 아키텍처, 트랜잭션, 인덱스 종류와 동작 방식, 옵티마이저와 힌트, 실행 계획에 대한 깊은 내용을 담고있다. DBA가 따로 없는 회사의 서버 개발자라면 이 책을 정말 추천한다. 물론 DBA가 있어도 이 책을 읽기를 추천한다. 다만 입문서는 아니다 보니 DB에 대해 잘 모른다면 좀 더 쉬운책을 2권정도 읽은 다음 이 책을 읽어보길 추천한다.
책을 통해서 배운것
이 책을 통해 배운것은 너무나도 많다. 'MySQL 아키텍처는 어떻게 되는가', 'InnoDB 아키텍처는 어떻게 되는가', 'InnoDB 아키텍처의 장점은 무엇인가', '쿼리는 어떻게 실행되는가', '트랜잭션 고립 레벨에 따라서 조회시 어떤 문제가 발생하는가', '인덱스는 어떻게 저장되고 어떻게 실행되는가', '스캔은 어떤 방식들이 있고 어떻게 스캔하는가', '클러스터링 인덱스와 논클러스터링 인덱스의 차이는 무엇인가', '조인은 어떻게 이루어지는가', '실행 계획에 뜻하는 내용들이 무엇인가', '인덱스 레인지 스캔, 인덱스 스킵 스캔, 인덱스 풀스캔, 테이블 풀스캔은 무엇인가' 등등 많은 내용을 배울 수 있었다.
책을 통해서 활용한 것
이 책을 개인적으로 공부하고 있을 때 마침 회사에서 슬로우 쿼리 튜닝하는 이슈를 할당 받았다. 당시 회사 서버에서는 몇몇 API에서 슬로우 쿼리가 발생했다. 처음 슬로우 쿼리 발견은 QA를 통해서 리포팅 되고 있었고 AWS CloudWatch에 API Log를 쌓고 있었다. CloudWatch는 필터링 기능을 제공하고 있는데 API Log에서 API 수행 시간이 3초 이상되는것을 필터링해서 API 로그를 따로 모아두었다. 그리고 그렇게 수행 시간이 오래걸리는 API들의 원인들을 분석해보면 쿼리 수행시간이 너무 오래 걸렸었다. 쿼리가 느린것은 어떻게 판단했냐면 문제가 될거같은 쿼리를 db client tool에서 explan 명령어를 통해서 실행계획을 살펴봤었다.
그중에 어떤 쿼리는 데이터 조회할때 인덱스를 비효율적으로 타고 있었다. 회사에서는 복합 칼럼 인덱스를 주로 사용하고 있었다. 옵티마이저는 복합 칼럼 인덱스가index(A칼럼, B칼럼)와 같이 걸려있다면 쿼리할때 where절에 A칼럼이 없을때 스킵 스캔을 하거나 인덱스 풀스캔을 한다. A칼럼이 유니크값이 많아서 그런지 내가 분석한 쿼리는 인덱스 풀스캔을 하고있었다. 그래서 많이 느릴때는 13초정도의 수행시간이 걸리고 있었다. 그래서 사용되는 쿼리 형태를 파악하고 인덱스 정책을 다시세웠다. 쿼리문중에 자주 where절에 들어가는 칼럼을 각각 쪼개서 인덱스를 걸어주었고 그 이후에 다시 explan으로 쿼리 실행계획을 살펴보니 1초 안쪽의 쿼리 수행시간이 걸렸다.
또 다른 활용 사례로는 서브쿼리인 inlineView를 이용하여 쿼리 튜닝을 진행했었다. 복잡한 비지니스 요구사항으로 원하는 데이터 칼럼들이 많아져 한 쿼리에 join문이 많아지면 인덱스만으로는 join 쿼리를 튜닝하기 쉽지 않아진다. 일반적으로 select문 쿼리 조회 순서는 select from -> where, join -> groupby -> distinct -> having -> orderby -> limit 순으로 실행되지만 inlineView를 사용하면 inlineView부터 먼저 실행된다. 그래서 원래 쿼리의 leftjoin을 제거하고 limit로 결과값의 개수를 줄인 inlineView를 만들었다. limit로 필터링 된 inlineView를 원래 쿼리의 from절에 넣어서 실행시켰고 기존보다 휠씬 빠른 성능 개선을 이룰 수 있었다.
이제와서 살펴보니 슬로우 쿼리 해결할때 아쉬운 부분이 있다. AWS Aurora의 DB slow query log를 cloudwatch에 바로 저장하는 방법이 있었다. 이 방법을 통해 슬로우 쿼리 로그를 보다 쉽게 수집할수 있었을 것이였다.
