개발서적/친절한 SQL 튜닝

NL 조인의 원리

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. NL 조인은 Nested Loop 조인의 약자로 중첩 루프 문과 같은 방법으로 조인이 이루어진다. 위 두 테이블를 사원 번호로 조인한다고 가정해보자. 프로그래밍 식으로 로직을 구현해보면 다음과 같이 할 수 있다. for(int i=0;i= '19960101' AND e.부서코드 = 'Z123' AND c.관리사원번호 = e.사원번호 AND c. 최종주문금액 >= 20000 위와 같은 쿼리를 실행 후, ROWS | OPERATION 5 |NESTED LOOPS 3 |TABLE ACCESS BY INDEX ROWID OF 사원 2780 | INDEX RANGE SCAN OF 사원_X1 5 | TABLE ACCESS BY INDE..

Where 조건 절에서 Between 과 Like

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. Between 과 Like의 스캔 범위 차이 Between 과 Like 는 범위 검색을 할 때 활용될 수 있는데, 언뜻 비슷해보이지만 효율적인 측면에서 살펴보면 다르게 동작한다. 예를 들어, 학생 테이블에 생년월 칼럼과 학점 칼럼이 있고 [생년월 + 학점] 이 인덱스라고 가정해보자. 1995년생이면서 학점이 'B'인 레코드들을 검색하기 위해서는 1️⃣ Between 의 경우 SELECT * FROM 학생 WHERE 생년월 BETWEEN "199501" AND "199512" AND 학점 = 'B'; 2️⃣ Like 의 경우 SELECT * FROM 학생 WHERE 생년월 LIKE "1995%" AND 학점 = 'B'; 와 같..

Where 조건 절에서 Between 과 in 의 차이

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. Between 과 In 조건절의 인덱스 스캔 범위 비교해보기 위와 같이, DEPTNO 와 JOB 으로 인덱스를 구성했다고 가정해보자. SELECT * FROM TABLE WHERE DEPTNO BETWEEN 10 AND 30 AND JOB = 'B' 위와 같은 쿼리가 실행되면 어떻게 될까? 먼저, DEPTNO가 10이면서 JOB이 'B' 인 레코드에서 탐색을 시작하여 DEPTNO 가 30이면서 JOB이 'B'가 아니게 되는 레코드 까지 탐색할 것이다. 수직적 탐색은 한번 이루어지지만, 수평적 탐색이 많은 레코드를 탐색하게된다. 반면에, SELECT * FROM TABLE WHERE DEPTNO IN (10,20,30) AND..

배치 I/O와 인덱스를 믿고 쿼리에 ORDER BY를 생략하면 안되는 이유

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. 인덱스의 비효율적인 랜덤 I/O 엑세스 인덱스는 큰 테이블에서 소량 데이터를 추출할때 유용하다고 배웠다. 인덱스로 레코드에 접근하는 경우, 인덱스와 연결된 해당 레코드가 존재하는 블록 정보를 통해서 레코드에 접근해야하기 때문에 랜덤 I/O 로 접근해야하고 이 랜덤 I/O가 많아지면, 전체 테이블을 풀 스캔해서 시퀀셜 엑세스로 접근하는게 비용이 더 적어질 수 있기 때문이다. 💡 이러한 성능 비효율을 어느정도 감소시키기 위해, 이전 인덱스를 통해 접근했던 테이블 블록 정보를 저장해두었다가 일치하면 바로 접근하는 캐싱 방법을 사용하긴하지만 인덱스로 정렬된 레코드마다 다른 블록을 가리키면 효과를 보기 힘든 방법이다. 그래서 고안해낸..

인덱스 튜닝

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. 인덱스를 통해 레코드를 찾아가는 과정 먼저, 인덱스를 활용할 수 있는 인덱스 테이블이 캐싱되어 있는지 확인한다. 캐싱되어 있다면, 인덱스 테이블에서 인덱스 조건에 맞는 레코드를 찾는다. 그러면, 해당 조건에 맞는 실제 디스크 상 레코드의 위치 정보를 파악할 수 있다.(ROWID) 실제 접근해야하는 디스크 상 레코드의 위치는 일반적으로 블록으로 관리하므로, 해당 블록이 이미 버퍼에 캐싱되어 있는지 확인하고 있다면 캐싱된 블록에 접근해서 가져온다. 만약, 그렇지 않다면 실제 디스크로 접근한다. 버퍼에서는 테이블 블록 위치 값을 해싱하여 고유한 값으로 변경 후 관리한다. 그 과정에서, 해싱 계산이 필요하므로 바로 주 메모리 위치를..

인덱스 컬럼 결정과 가공

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. 인덱스 스캔 데이터를 찾는 방법은 크게 2 가지로 나눌 수 있다. 1. 테이블 전체 스캔 2. 인덱스 스캔 테이블 전체 스캔은 말 그대로, 테이블 데이터가 저장되어 있는 블록 전체를 스캔한다. 인덱스 스캔은 인덱스로 설정한 기준에 따라 일정량을 스캔한다. ❓ 인덱스 스캔 방식이 항상 유리할까? 그렇지 않다. 💡 인덱스 스캔 방식은 큰 테이블에서 소량의 데이터를 찾고자 할때 유용하다. 예로, 전체 테이블 스캔을 진행하면 버퍼 캐시에 데이터가 존재하지 않을 시, 모든 레코드를 탐색하므로 오랜 시간이 소요될 수 있다. 하지만, 한번 가져오고 난 뒤에는 해당 테이블과 관련한 데이터는 물리적 I/O 없이 탐색할 수 있다. 인덱스 스캔..

SQL 처리 과정과 I/O

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. SQL 처리 과정 SQL파싱과 최적화 1️⃣ SQL 파싱 사용자로부터 SQL을 전달받으면 SQL 파서가 파싱을 진행한다. 💡 SQL 문을 이루는 개별 구성 요소를 분석하여 파싱 트리를 생성한다. 💡 그리고 전달 받은 SQL 문에서 문법적 오류 (사용할 수 없는 키워드 사용 등) 나 의미상 오류(존재하지 않는 테이블 혹은 컬럼 사용 등)가 존재하는지 확인한다. 2️⃣ SQL 최적화 💡 옵티마이저는 다양한 실행 경로를 생성해서 비교한 후, 가장 효율적인 하나를 선택한다. 그렇게 선택한 경로를 실행 가능한 코드 또는 프로시저 형태로 포맷팅한다. 실행 계획과 비용 MySQL 서버로 요청된 쿼리는 결과는 동일하지만 그 결과를 만들어 ..