📑 로그

이 글을 시작으로 간단한 쿼리 개선 중 알게 된 지식들과 그 과정을 적어보고자 한다.먼저 쿼리 개선을 위해서는 현재 내가 작성한 쿼리의 성능을 테스트 해봐야 한다.MySQL서버에서 직접 테스트를 진행했을 때 첫 쿼리 실행 시간과 다음 쿼리 실행시간의 차이가 매우 크고 그 이후의 쿼리 실행시간들도 제각각이라는 것을 확인했다. 이에 성능 테스트의 일관성을 유지하기 위해 실제 쿼리가 실행될 때 거치는 과정들을 학습하면서 변수들을 최소화하고자 했다.  ☑️ 쿼리의 성능에 영향을 미치는 요소 1️⃣ 운영체제의 캐시MySQL 서버는 시스템 콜을 이용해 데이터 파일을 읽어온다. 그런데 일반적으로 대부분의 운영체제는 한 번 읽은 데이터는 운영체제가 관리하는 별도의 캐시 영역에 보관해 뒀다가 다시 해당 데이터가 요청되면..

DB에 대해 공부하던 중, 문득 이때까지 프로젝트를 진행하면서 단 한번도 DB에서 일어나는 동시성 문제에 대해 고려해본적이 없다는 생각이 들었다. 그래서 이번에는 DB 동시성 문제 해결 과정에 대해 이야기할 것이며 먼저 이번 글에서는 자주 헷갈리는 부분인 트랜잭션 격리 수준과 MySQL 락에 관해 간단하게 정리해보고자 한다. 이 글은 대부분 저의 기억을 상기하여 짧게 쓴 글이기 때문에 자세한 정보를 원하신다면 MySQL 도큐먼트를 추천합니다.    MySQL에서 사용되는 락은 크게 스토리지 엔진 레벨과 MySQL 엔진 레벨로 나눌 수 있다. 스토리지 엔진 레벨의 잠금은 테이블의 데이터를 다루기 위한 락이며, MySQL 엔진 레벨의 잠금은 테이블이나 데이터베이스 등을 위한 락에 해당한다.  ☑️ InnoD..

버퍼 풀은 디스크의 데이터와 인덱스를 캐시하는 역할과 쓰기 작업을 지연시켜 일괄처리하는 역할을 한다.일반적으로 데이터를 변경하는 쿼리는 랜덤한 디스크 작업을 발생시킨다. 하지만 버퍼 풀이 이러한 변경된 데이터를 일괄 처리하게 되면 랜덤한 디스크 작업의 횟수를 줄일 수 있다.그 밖에도 InnoDB의 버퍼 풀은 많은 백그라운드 작업의 기반이 되는 공간이다. 버퍼 풀은 메모리 내에 위치하며 크게 디스크에서 읽어온 데이터와 인덱스를 캐시해두는 '데이터 페이지 버퍼'와 MVCC를 위한 '언두 로그', 인덱스 업데이트 성능 향상을 위한 '인서트(체인지) 버퍼'로 구성된다.버퍼 풀 자체는 세마포어로 관리되며 기존 1개의 인스턴스에서, 최근에는 기본 8개의 인스턴스를 지원한다.    ☑️ 버퍼 풀 페이지 저장 메커니즘..

성능 테스트를 진행하면서 MySQL의 내부 구조를 자세히 모르고 있다는 생각이 들었다. 특히 InnoDB 버퍼 풀이라는 공간은 버퍼와 캐시의 역할을 하는 것으로 알고있는데, 그렇다면 이 부분이 성능 측정에 영향을 줄 뿐더러, 쿼리 특성에 따라 적절히 조절한다면 성능 향상에 도움이 될 수도 있겠다라는 생각에서 공부를 시작했고 그 과정에서 알게된 것들을 앞으로 2~3개의 글에서 다뤄보고자 한다.    ☑️ MySQL 아키텍처 MySQL 아키텍처는 크게 MySQL엔진과 스토리지 엔진으로 이루어져 있다. 이 글에서 스토리지 엔진은 현재 MySQL의 기본 스토리지 엔진인 InnoDB를 기준으로 다룬다. MySQL 엔진은 클라이언트로부터의 요청, 즉 쿼리를 분석하고 최적화하는 역할을 하며, 스토리지 엔진은 직접 디..

쿼리 성능 개선은 쿼리문 내에서 Join문과 서브쿼리를 개선하는 것이 전부인줄 알았던 나...이번 쿼리 성능 개선을 통해 인덱스 최적화, 샤딩, 파티셔닝, 캐싱, 정규화와 비정규화 등 정말 많은 방법이 있다는 것을 알게 되었고 쿼리 개선에 흥미가 붙기 시작했다. 이번 성능 개선에서 내가 사용한 방법은 인덱스 최적화이다.먼저 인덱스에 대한 개념들을 짚고 넘어가자개선하고자 하는 API는 '필드' 테이블을 조회하는 페이징 API이다. 해당 API는 Count 쿼리와 일반 조회 쿼리, 총 2개의 쿼리가 실행된다.   ☑️ 조회 쿼리 1️⃣ 클러스터링 인덱스 사용먼저 쿼리 개선을 위해서는 실행계획을 통해 쿼리가 어떻게 실행되는지를 확인해야한다.  type - ALL : 인덱스를 타지 않은 테이블 풀스캔을 의미한다..