요약 MySQL 의 실행 계획을 설정하는 방법을 이해하게 됨. 통계 정보 활용 테이블의 데이터나 인덱스를 이용하여 통계 정보를 사용함. 히스토그램을 통해 데이터 분포도를 알게 되기에 특정 범위의 데이터가 많고 적음을 알 수 있음. 따라서, 히스토그램을 통해 쿼리의 최적의 실행 계획을 만들어 낼 수 있다. 코스트 모델에 대해 이해하게 됨. MySQL 엔진이 쿼리를 처리할 때 여러 작업을 필요로 하는데, 코스트 모델에 대한 단위 작업들을 변경에 따른 비용 혹은 실행 계획의 변화를 알 수 있음. 메모 실행 계획 대부분의 RDBMS는 많은 데이터를 안전하게 저장 및 관리하고 사용자가 원하는 데이터를 빠르게 조회할 수 있게 해주는 것이 주목적임. 이 목적을 달성하려면 옵티마이저가 사용자의 쿼리를 최적으로 처리될 ..
요약 인덱스 힌트 중, SQL_CACL_FOUND_ROWS 에 대한 내용을 알게 됨. LIMIT 에 명시된 수만큼의 만큼의 레코드 뿐만 아니라 끝까지 검색을 수행함 이 힌트는 사용하지 않는 방향을 추천함. 옵티마이저 힌트에 대한 내용과 그 종류를 알게 됨. 인덱스, 테이블, 쿼리 블록, 글로벌의 옵티마이저 종류가 있음. MAX_EXECUTION_TIME SET_VAR SEMIJOIN & NO_SEMIJOIN SUBQUERY BNL & NO_BNL & HASHJOIN & NO_HASHJOIN JOIN_FIXED_ORDER & JOIN_ORDER & JOIN_PREFIX & JOIN_SUFFIX MERGE & NO_MERGE INDEX_MERGE & NO_INDEX_MERGE NO_ICP SKIP_SCAN ..
요약 옵티마이저 스위치 옵션중, 인덱스 정렬 선호에 대한 최적 방법을 알게 됨. ORDER BY, GROUP BY에 대한 인덱스 가중치를 높이 설정할 수 있게 함. 조인 최적화 알고리즘에 대한 내용을 이해하게 됨. Exhaustive 검색 알고리즘 실행 계획 수립에 상당한 시간이 소요됨 (오래된 버전에 사용되었음) Greedy 검색 알고리즘 최소 비용을 계산하여 최적의 조인 형태를 찾아냄. 휴리스틱 검색을 통해, 그때그때 최적의 방법을 찾아냄 쿼리 힌트에 대해 이해하게 됨. 인덱스 힌트 STRAIGHT_JOIN 조인 순서 고정 USE INDEX / FORCE INDEX / IGNORE INDEX 인덱스 사용 & 스킵 하도록 설정 옵티마이저 힌트 메모 인덱스 정렬 선호(prefer_ordering_inde..
요약 세미조인의 최적화 나머지 부분을 이해하게 됨. 컨디션 팬아웃 드라이빙 테이블, 드리븐 테이블을 최적 조건을 찾아 선정함. 옵티마이저가 레코드 건수를 예측하여 성능을 향상시킴 파생 테이블 머지 FROM 절에 사용된 서브 쿼리를 임시 테이블로 만들어 외부 쿼리와 병합하여 최적화함. 인비저블 인덱스 인덱스가 설정되어 있더라도 무시할 수있도록 사용할 수 있음. 스킵 스캔 인덱스 값이 정렬되어 있어서 가능함. 인덱스의 선행 칼럼이 조건절에 없어도 후행 칼럼만으로 인덱스를 이용한 쿼리 성능 가능 → 인덱스 스킵했기에 가능 선행 칼럼이 다양한 값을 가지면 스킵 스캔은 비효율 적일 수 있음. 해시 조인 첫번째 레코드 찾는데는 오래 걸리지만, 실행 속도가 그만큼 빠름. 실제로 레코드 건수가 적은 경우에만 사용하고는..
요약 세미조인 최적화의 방법 중, 일부를 이해하게 됨. 테이블 풀-아웃 서브쿼리 → 아우터 쿼리로 끄집어낸 후 쿼리를 조인 쿼리로 재작성 퍼스트 매치 EXISTS(subquery)로 최적화함. 단축 실행 경로로 수행함. (서브쿼리가 참조하는 모든 아우터 테이블이 먼저 조회된 이후에 실행됨) 루스 스캔 루스 인덱스 스캔와 비슷한 방식으로 스캔함. 구체화 서브쿼리를 통째로 구체화 하여 최적화 함. → 내부 임시테이블을 생성함. 중복 제거 세미조인 서브쿼리 → INNER JOIN + 중복 제거 처리를 최적화함. 메모 세미조인 최적화 1-1 테이블 풀-아웃(Table Pull-out) Table pullout 최적화는 세미 조인의 서브쿼리에 사용된 테이블을 아우터 쿼리로 끄집어낸 후에 쿼리를 조인 쿼리로 재작성..
요약 인덱스 머지에 대한 내용을 이해하게 됨. 교집합 합집합 정렬 후 합집합 에 대한 내용의 실행 계획과 어떤 알고리즘(ex: 합집합 → 우선순위 큐)을 사용했는지 알게 됨. 세미 조인에 대한 내용을 알게 됨. 다른 테이블에 조건이 일치하는지만 판단함 (실제 조인은 X) 세미 조인, 안티 세미 조인에 따라 최적화 형태가 다름 8.0 버전부터 세미 조인 쿼리 최적화를 위한 전략들이 있음. 메모 인덱스 머지(index_merge) 인덱스를 이용하여 쿼리를 실행할 때, 대부분의 옵티마이저는 테이블별로 하나의 인덱스만 사용하도록 실행 계획을 수립함. 하지만, 인덱스 머지 실행 계획을 사용하면 하나의 테이블에 대해 2개 이상의 인덱스를 이용하여 쿼리를 처리함. 일반적으로, 쿼리에서 한 테이블에 대한 WHERE 조..
요약 MySQL 의 옵티마이저의 고급 최적화에 대한 내용을 알게됨. 통계 정보, 옵티마이저 옵션을 결합하여 실행계획을 수립함. 옵티마이저 옵션을 이용 → 조인이 많이 사용되는 서비스에 사용 스위치 → 고급 최적화 기능을 제어하는 용도로 사용 옵티마이저 스위치 옵션을 이해하게 됨. 글로벌, 세션별 설정이 가능함. MRR & 배치 키 액세스 블록 네스티드 루프 조인 인덱스 컨디션 푸시다운 인덱스 확장 에 대한 내용을 통해 실행 계획의 결정을 예시를 통해 잘 이해할 수 있었음. 메모 고급 최적화 MySQL 서버의 옵티마이저가 실행 계획을 수립할 때 통계 정보와 옵티마이저 옵션을 결합해서 최적의 실행 계획을 수립함. 옵티마이저 옵션은 크게 아래와 같이 구분할 수 있다. 조인 관련된 옵티마이저 옵션 MySQL 서..
요약 GROUP BY 의 동작방식을 이해하게 됨. 인덱스 스캔을 이용 루스 인덱스 스캔 이용 임시 테이블 이용 DISTINCT 의 동작방식을 이해하게 됨. SELECT DISTINCT … 이용 집합함수와 함께 이용 MySQL 엔진에서 내부 임시 테이블을 사용하는 방법을 이해하게 됨. 쿼리 처리 완료시 삭제됨. 메모리 임시 테이블과 디스크 임시 테이블로 나눠짐. 임시 테이블이 필요한 쿼리 패턴을 알게 됨. 임시 테이블이 디스크에 생성되는 조건을 알게 됨. 임시 테이블이 사용됬는지 상태변수를 통해 확인할 수 있음. 메모 GROUP BY 처리 GROUP BY 또한 ORDER BY 와 같이 쿼리가 스트리밍된 처리를 할 수 없게 하는 처리 중 하나임. HAVING 절은 GROUPBY 결과에 대해 필터링 역할을 수..
요약 이번 장은 개인적으로 가장 궁금한 점을 해소할 수 있었다. 실행 계획을 보면서 최대한 쿼리 최적화하는 실습을 한 적이 있었는데, 특히 드라이빙 테이블이 선정되는 조건을 제대로 이해하지 못했었는데, 책을 읽으면서 정리가 되어 좋았다. 정렬 처리 방법을 3가지 방식으로 옵티마이저가 처리함. 인덱스를 이용한 정렬 조인의 드라이빙 테이블만 정렬 조인 결과를 임시 테이블로 저장 후 정렬 조건 절에 쓰인 칼럼과 ORDER BY 에 쓰인 칼럼이 어떤 테이블 (드라이빙 or 드리븐)에 속해있는지에 따라 드라이빙 테이블이 결정되고, 위 정렬 방식중 한가지가 선택됨. 정렬 처리 방법에 대한 성능에 대한 비교를 생각해 볼 수 있었음. 쿼리에 있는 LIMIT 은 스트리밍 방식이냐, 버퍼링 방식이냐에 따라 우리가 원하는 ..
요약 MySQL의 기본 데이터 처리 방식에 대해 이해하게 됨. 풀 테이블 스캔과 풀 인덱스 스캔의 결정 조건을 알게 됨. 풀 테이블 스캔 시, InnoDB 스토리지 엔진에서는 리드 어헤드를 통해 백그라운드 스레드가 예측되어 미리 디스크에 읽어진 데이터 페이지를 읽어들임. 하나의 쿼리를 병렬로 처리할 수 있다는 사실을 알게 됨. 정렬 방식으로 인덱스와 파일소트 방식을 알게됨. 정렬을 수행하는 별도 메모리인 소트 버퍼에 대해 알게 됨. 정렬 레코드 건수가 소트 버퍼가 감당할 메모리 보다 크다면 멀티 머지가 이루어지게 됨. 정렬 알고리즘의 2가지 방식을 알게 됨 싱글 패스 정렬 방식 → 조회 대상 칼럼을 모두 디스크에서 읽어서 정렬 투 패스 정렬 방식 → 정렬 대상 칼럼 & 프라이머리 키 칼럼을 디스크에서 읽..
요약 유니크 인덱스에 대해 이해하게 됨. 유니크 인덱스와 일반 세컨더리의 차이를 이해하게 됨. 인덱스 읽기 관점에서, 성능 차이는 미미함. (일반 세컨더리 인덱스에서 데이터를 더 많이 읽어오더라도, 속도 자체는 거의 동일함) 인덱스 쓰기 관점에서 중복 체크 때문에 유니크 인덱스가 더 느림. 유니크 인덱스 생성시 주의사항을 이해하게 됨. 중복된 인덱스를 적용할 필요가 없다. 유일성이 꼭 보장되어야 하는 칼럼에 대해서 유니크 인덱스를 생성하되, 꼭 필요하지 않으면 유니크 인덱스보다는 유니크하지 않은 세컨더리 인덱스를 생성하는 방향으로 가자. 외래키에 대한 내용을 이해하게 됨. InnoDB 스토리지 엔진에서만 사용 가능. 외래키로 인한 부모, 자식의 쓰기 잠금 경합이 발생할 수 있음. 쿼리 처리 성능이 떨어질..
요약 멀티 밸류 인덱스에 대해 이해하게 됨. 하나의 데이터 레코드에 여러 개의 키 값을 가질 수 있음. ex) JSON 포맷의 데이터에 멀티 밸류 인덱스를 지원함. 클러스터링 인덱스에 대해 이해하게 됨. 클러스터링 인덱스는 테이블의 프라이머리 키에대해서만 적용됨 프라이머리 키 값에 의해 레코드 저장위치가 결정됨. 프라이머리 키가 없다면 InnoDB 스토리지 엔진이 내부적으로 대체할 칼럼에 대한 일련번호를 부여함 대신, 사용자가 이 값을 알 방법이 없어서 크게 의미가 없음. 세컨더리 인덱스에 대해 이해하게 됨. 세컨더리 인덱스는 레코드의 주소를 가지고 있음. InnoDB 스토리지 엔진에서 세컨더리 인덱스가 레코드의 주소를 알고 있다면 클러스터링 키 값이 변경되면 주소 값 자체를 계속 변경해야함. → 오버헤..