이번에는 생애 처음으로 토이 프로젝트의 쿼리를 튜닝해보았습니다. 프로젝트에서 제일 많이 호출되는 쿼리를 튜닝했는데 그 경험을 적어보겠습니다. 쿼리 튜닝 환경 M1 air RAM 16GB, SSD 512GB Docker 컨테이너 Mysql 8.x 버전 다대다 관계 튜닝하기 project라는 테이블과 member라는 테이블은 다대다 관계다. 중간 관계 테이블로 project_member라는 테이블이 존재한다. 테스트 데이터는 MySQL 프로시저를 활용해서 주입했으며 데이터 갯수는 아래와 같다. member: 200만 project: 500만 project_member: 1400만 먼저 쿼리를 살펴보자. 내가 참여한 모든 프로젝트를 조회하는 쿼리다. 디스코드 사이드 바에서 내가 참여한 모든 채팅방을 보여줄 때..
NL 조인 조인의 기본은 NL 조인이다. NL은 Nested Loops 조인의 약어다. 즉 중첩 루프문과 같은 수행 구조를 사용한다. 일반적으로 NL 조인은 Outer와 Inner 양쪽 테이블 모두 인덱스를 사용한다. Outer 쪽 테이블은 사이즈가 크지 않으면 인덱스를 이용하지 않을 수 있다. Table Full Scan 하더라도 그것은 한 번에 그치기 때문이다. Inner 쪽 테이블은 인덱스를 사용해야 한다. Inner 루프에서 외래키로 데이터를 검색할 때 인덱스를 이용하지 않으면, Outer 루프에서 읽은 건수만큼 Table Full Scan을 반복하기 때문이다. NL 조인은 '인덱스를 이용한 조인 방식'이라고 할 수 있다. 튜닝 포인트 Outer Table 인덱스를 읽고 나서 Outer Table..
1. 테이블 액세스 최소화 테이블 랜덤 액세스 인덱스 ROWID는 물리적 주소? 논리적 주소? 인덱스를 스캔하는 이유는, 검색 조건을 만족하는 소량의 데이터를 인덱스에서 빨리 찾고 거기서 테이블 레코드를 찾아가기 위한 주소 값, 즉 ROWID를 얻으려는 데 있다. 인덱스 ROWID는 물리적 주소보다 논리적 주소에 가깝다. 물리적으로 직접 연결되지 않고 테이블 레코드를 찾아가기 위한 논리적 주소 정보를 담고 있기 때문이다. ROWID는 프로그래밍에서 말하는 포인터가 아니며, 테이블 레코드와 물리적으로 직접 연결된 구조는 더더욱 아니다. 오라클 같은 경우는 테이블 블록이 수시로 버퍼캐시에서 밀려났다가 다시 캐싱되며, 그때마다 다른 공간에 캐싱되기 때문에 인덱스에서 포인터로 직접 연결할 수 없는 구조다. 메모..
인덱스 구조 및 탐색 RDBMS 테이블에서 데이터를 찾는 방법은 두 가지다. 테이블 전체 스캔 인덱스 이용 인덱스는 큰 테이블에서 소량 데이터를 검색할 때 사용한다. 세부적인 인덱스 튜닝 방법의 핵심은 크게 두 가지다. 첫 번째는 인덱스 스캔 과정에서 발생하는 비효율을 줄이는 것이다. 즉, 인덱스 스캔 효율화 튜닝이다. 두 번째는 테이블 액세스 횟수를 줄이는 것이다. 인덱스 스캔 후 테이블 레코드를 액세스할 때 랜덤 I/O 방식을 사용하므로 이를 '랜덤 액세스 최소화 튜닝'이라고 한다. 둘 중 더 중요한 것은 랜덤 액세스 최소화 튜닝이다. 결국 SQL 튜닝은 랜덤 I/O와의 전쟁이다. DB 성능이 느린 이유는 디스크 I/O 때문이다. 읽어야 할 데이터량이 많고, 그 과정에 디스크 I/O가 많이 발생할 때..
