MySQL

MySQL 아키텍처 MySQL 서버의 종류 MySQL 서버는 MySQL 엔진과 스토리지 엔진으로 구분할 수 있다. MySQL 엔진: 사람의 머리 역할 스토리지 엔진: 손발 역할 핸들러 API를 만족하면 누구든지 구현해서 MySQL 서버에 추가해서 사용할 수 있다. MySQL 서버에서 기본으로 제공되는 InnoDB 스토리지 엔진 M...

InnoDB MySQL의 스토리지 엔진 가운데 가장 많이 사용된다. MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공한다. 그 때문에 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다. InnoDB 구조 > 출처

MyISAM 스토리지 엔진 아키텍처 MyISAM 스토리지 엔진의 성능에 영향을 미치는 요소인 키 캐시와 운영체제의 캐시/버퍼에 대해 살펴본다. Key cacge (키 캐시, 키 버퍼) InnoDB의 버퍼 풀과 비슷한 역할을 한다. MyISAM 키 캐시는 인덱스만을 대상으로 작동하며, 인덱스의 디스크 쓰기 작업에 대해서만 부분적으로 버퍼링 역할을 한다....

로그 파일을 이용하면 MySQL 서버의 깊은 내부 지식이 없어도 MySQL 상태나 부하를 일으키는 원인을 쉽게 찾아서 해결할 수 있다.MySQL 서버에 문제가 생겼을 때는 다음 로그 파일들을 자세히 확인하는 습관을 들일 필요가 있다.에러 로그 파일제너럴 쿼리 로그 파일

트랜잭션 트랜잭션이란 트랜잭션은 작업의 완전성을 보장해 주는 것이다. 논리적인 작업 셋을 모두 완벽하게 처리하거나 처리하지 못할 경우 원 상태로 복구 작업의 일부만 적용되는 현상(Partial update)이 발생하지 않게 해주는 기능이다. 트랜잭

MySQL에서 사용되는 잠금은 크게 두 가지 레벨로 나눌 수 있다.스토리지 엔진 레벨의 잠금스토리지 엔진 간 상호 영향을 미치지는 않는다.MySQL 엔진 레벨의 잠금MySQL 엔진: MySQL 서버에서 스토리지 엔진을 제외한 나머지 부분모든 스토리지 엔진에 영향을 미친

InnoDB 스토리지 엔진 잠금 InnoDB 스토리지 엔진에서 제공하는 잠금 InnoDB 스토리지 엔진은 레코드 기반의 잠금 기능을 제공한다. 레코드 기반의 잠금 방식 때문에 MyISAM 보다는 훨씬 뛰어난 동시성 처리를 제공할 수 있다. 이원화된 잠금 처리 탓에 InnoDB 스토리지 엔진에서 사용되는 잠금에 대한 정보는 MySQL 명령을 이용해...

MySQL의 격리 수준 격리 수준이란 트랜잭션의 격리 수준(isolation level)이란, 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다. 격리 수준 4가지 READ UNCOMMITTED READ COMMITTED REPEATABLE ...

디스크 읽기 방식 데이터 저장 매체는 컴퓨터에서 가장 느린 부분이다. 데이터베이스의 성능 튜닝은 어떻게 디스크 I/O를 줄이느냐가 관건일 때가 상당히 많다. HDD와 SSD 컴퓨터에서 CPU나 메모리 같은 주요 장치는 대부분 전자식 장치지만, 하드 디스크 드라이브는 기계식 장치다. 그래서 데이터베이스 서버에서는 항상 디스크 장치가 병목이 된다. 디스크...

쿼리 튜닝의 기본이다.많은 곳에서 책의 ‘색인’으로 설명된다.책의 내용: 데이터 파일책의 ‘색인’으로 알아낼 수 있는 페이지 번호: 데이터 파일에 저장된 레코드의 주소데이터베이스 테이블의 모든 데이터를 검색해서 원하는 결과를 가져오려면 시간이 오래 걸리므로, 인덱스를

B-Tree 인덱스 데이터베이스의 인덱싱 알고리즘 가운데 가장 일반적으로 사용되고, 가장 먼저 도입된 알고리즘 아직도 가장 범용적인 목적으로 사용되는 인덱스 알고리즘 전문 검색과 같은 특수한 요건이 아닌 경우, 대부분 인덱스는 거의 B-Tree를 사용한다. “

R-Tree 인덱스 공간 인덱스 (Spatial Index) 공간 인덱스란 R-Tree 인덱스 알고리즘을 이용해 2차원의 데이터를 인덱싱하고 검색하는 목적의 인덱스다. 기본적인 내부 메커니즘은 B-Tree와 흡사하다. B-Tree는 인덱스를 구성하는 칼럼의 값이 1차원의 스칼라 값인 반면, R-Tree 인덱스는 2차원 공간 개념 값이다. MySQL의...

앞서 정리한 인덱스 알고리즘은 일반적으로 크지 않은 데이터 또는 이미 키워드화한 작은 값에 대한 인덱싱 알고리즘이다.MySQL의 B-Tree 인덱스는 실제 칼럼의 값이 1MB더라도 1000바이트(MyISAM) 또는 3072바이트(InnoDB)까지만 잘라서 인덱스 키로

일반적인 인덱스는 칼럼의 값 일부(칼럼의 값 앞부분) 또는 전체에 대해서만 인덱스 생성이 허용된다.칼럼의 값을 변형해서 만들어진 값에 대해 인덱스를 구축해야 할 때 함수 기반의 인덱스를 활용한다.MySQL 8.0부터 함수 기반 인덱스를 지원하기 시작했다.MySQL 서버

멀티 밸류 인덱스 전문 검색 인덱스를 제외한 모든 인덱스는, 인덱스 키와 데이터 레코드가 1:1 관계를 가진다. 멀티 밸류(Multi-Value) 인덱스는 하나의 데이터 레코드가 여러 개의 키 값을 가질 수 있는 형태의 인덱스다. 일반적인 RDBMS를 기준으로 생각하면 이러한 인덱스는 정규화에 위배되는 형태다. 하지만 최근 RDBMS들이 J...

클러스터링 인덱스 클러스터링이란 여러 개를 하나로 묶는다는 의미이다. MySQL 서버에서 클러스터링은 테이블의 레코드를 비슷한 것(프라이머리 키를 기준으로)들끼리 묶어서 저장하는 형태로 구현된다. 주로 비슷한 값들을 동시에 조회하는 경우가 많다는 점에서 착안한 것이다. MySQL에서 클러스터링 인덱스는 InnoDB 스토리지 엔진에서만 지원하며, 나...

유니크 인덱스 유니크 인덱스란 유니크는 테이블이나 인덱스에 같은 값이 2개 이상 저장될 수 없음을 의미한다. 사실 인덱스라기보다는 제약조건에 가깝다고 볼 수 있다. 유니크 인덱스에서 NULL도 저장될 수 있다. NULL은 특정 값이 아니므로 2개 이상 저장될 수 있다. MySQL에서는 인덱스 없이 유니크 제약만 설정할 방법이 없다. MyS...

외래키 MySQL의 외래키 InnoDB 스토리지 엔진에서만 생성할 수 있다. 외래키 제약이 설정되면 자동으로 연관되는 테이블의 칼럼에 인덱스까지 생성된다. 외래키가 제거되지 않은 상태에서는 자동으로 생성된 인덱스를 삭제할 수 없다. 외래키의 특징 테이블의 변경(쓰기 잠금)이 발생하는 경우에만 잠금 경합(잠금 대기)이 발생한다. 외래키와 연관되지 않은...

옵티마이저는 쿼리의 실행 계획을 수립한다.실행 계획을 이해할 수 있어야만 실행 계획의 불합리한 부분을 찾아내고, 더 최적화된 방법으로 실행 계획을 수립하도록 유도할 수 있다.MySQL 서버에서 쿼리가 실행되는 과정은 크게 세 단계로 나눌 수 있다.사용자로부터 요청된 S

MySQL 서버를 포함한 모든 RDBMS는 데이터를 정렬하거나 그루핑하는 등의 기본 데이터 가공 기능을 가지고 있다.결과물은 동일하더라도 RDBMS 별로 그 결과를 만들어 내는 과정은 다르다.MySQL 서버가 이러한 기본적인 가공을 위해 어떤 알고리즘을 사용하는지 살펴

여기서 설명하는 병렬 처리는 하나의 쿼리를 여러 스레드가 작업을 나누어 동시에 처리한다는 것을 의미한다.MySQL 8.0 버전부터 용도가 한정되어 있긴 하지만 MySQL 서버에서도 쿼리의 병렬 처리가 가능해졌다.아직 쿼리를 여러 개의 스레드를 이용해 병렬로 처리하게 하

ORDER BY 처리 정렬 처리 레코드 1~2건을 가져오는 쿼리를 제외하면 대부분의 SELECT 쿼리에서 정렬은 필수적으로 사용된다. 데이터 웨어하우스처럼 대량의 데이터를 조회해서 일괄 처리하는 기능이 아니라면 아마도 레코드 정렬 요건은 대부분의 조회 쿼리에 포함되어 있을 것이다. 정렬을 처리하는 방법은 크게 인덱스를 이용하는 방법과 쿼리가 실행될 때 ...

ORDER BY와 같이 쿼리가 스트리밍된 처리를 할 수 없게 하는 처리 중 하나다.GROUP BY 절이 있는 쿼리에서는 GROURP BY 결과에 대해 필터링 역할을 수행하는 HAVING 절을 사용할 수 있다.GROUP BY에 사용된 조건은 인덱스를 사용해서 처리될 수

특정 칼럼의 유니크한 값만 조회하려면 SELECT 쿼리에 DISTINCT를 사용한다.DISTINCT 키워드는 다음 경우에 영향을 미치는 범위가 달라진다.MIN(), MAX(), COUNT() 같은 집합 함수와 함께 사용되는 경우집합 함수가 없는 경우집합 함수와 같이 D

MySQL 엔진이 스토리지 엔진으로부터 받아온 레코드를 정렬하거나 그루핑할 때는 내부적인 임시 테이블을 사용한다.여기서 이야기하는 임시 테이블은 CREATE TEMORARY TABLE 명령으로 만든 임시 테이블과는 다르다.CREATE TEMORARY TABLE 명령으로

MySQL 서버의 옵티마이저가 실행 계획을 수립할 때 통계 정보와 옵티마이저 옵션을 결합해서 최적의 실행 계획을 수립하게 된다.옵티마이저 옵션은 크게 다음 두 가지로 구분할 수 있다.조인 관련된 옵티마이저 옵션옵티마이저 스위치MySQL 서버 초기 버전부터 조인 관련된

MySQL 서버에서 지금까지 지원하던 조인 방식드라이빙 테이블의 레코드를 한 건 읽어서 드리븐 테이블의 일치하는 레코드를 찾아서 조인을 수행하는 방식이다.드라이빙 테이블: 조인에서 제일 먼저 읽는 테이블드리븐 테이블: 조인되는 테이블에서 드라이빙이 아닌 테이블들MySQ

MySQL 서버에서 사용되는 대부분의 조인 방식이다.조인의 연결 조건이 되는 칼럼에 모두 인덱스가 있는 경우 사용된다.레코드를 읽어서 다른 버퍼 공간에 저장하지 않고, 즉시 드리븐 테이블의 레코드를 찾아서 반환한다.다음과 같이 프로그래밍 언어에서 마치 중첩된 반복 명령

인덱스 컨디션 푸시다운 기존 방식 MySQL 5.5 버전까지는 인덱스를 범위 제한 조건으로 사용하지 못하는 조건은 MySQL 엔진이 스토리지 엔진으로 아예 전달하지 않았다. Extra 칼럼의 “Using where”는 InnoDB 스토리지 엔진이 읽어서 반환해준 레코드가 인덱스를 사용할 수 없는 WHERE 조건에 일치하는지 검사하는 과정을 의미한...

InnoDB 스토리지 엔진은 프라이머리 키를 클러스터링 키로 생성하므로, 모든 세컨더리 인덱스는 리프 노드에 프라이머리 키 값을 가진다.아래의 테이블을 보자.프라이머리 키: (demp_no, emp_no)세컨더리 인덱스 ix_fromdate: from_date세컨더리

인덱스 머지 Index Merge 인덱스를 이용해 쿼리를 실행하는 경우, 대부분 옵티마이저는 테이블 별로 하나의 인덱스만 사용하도록 실행 계획을 수립한다. 쿼리에서 한 테이블에 대한 WHERE 조건이 여러 개 있더라도 하나의 인덱스에 포함된 칼럼에 대한 조건만으로 인덱스를 검색하고, 나머지 조건은 읽어온 레코드에 대해서 체크하는 형태로만 사용되는...

MySQL 5.7 서버는 전통적으로 세미 조인 형태의 쿼리를 최적화하는 부분이 상당히 취약했다.예전 처리 방식을 확인해보고 싶다면 세미 조인 최적화를 off로 변경하면 된다.다음 쿼리는 employees 테이블을 풀 스캔하면서 한 건 한 건 서브쿼리의 조건에 일치하는지

세미 조인 최적화 MySQL 서버 8.0 버전부터는 세미 조인 쿼리의 성능을 개선하기 위한 다음과 같은 최적화 전략이 있다. Table Pull-out Duplicate Weed-out First Match Loose Scan Materialization MySQL 서버 매뉴얼에서는 이 최적화 전략들을 모아서 세미 조인 ...

컨디션 팬아웃 조인의 순서와 성능 조인을 실행할 때 테이블의 순서는 쿼리의 성능에 매우 큰 영향을 미친다. 어떤 테이블이 드라이빙 테이블이 되느냐에 따라 달라진다. 예를 들어, 일치하는 레코드가 1만 건인 A테이블과 레코드가 10건인 B테이블을 조인할 때, A 테이블이 드라이빙 테이블이 되면 B테이블의 인덱스를 이용해 조인을 실행하더라도 ...

파생 테이블 머지 예전 버전의 파생 테이블 예전 버전의 MySQL 서버는 FROM 절에 사용된 서브쿼리는 먼저 실행해서 그 결과를 임시 테이블로 만든 다음 외부 쿼리 부분을 처리했다. 내부적으로 임시 테이블을 생성하고, 서브쿼리를 실행(SELECT)하여 임

MySQL 8.0 이전 버전까지는 인덱스가 존재하면 항상 옵티마이저가 실행 계획을 수립할 때 해당 인덱스를 검토하고 사용했다.MySQL 8.0 버전부터 인덱스의 가용 상태를 제어할 수 있는 기능이 추가되었다.인덱스를 삭제하지 않고, 해당 인덱스를 사용하지 못하게 제어하

인덱스의 핵심은 값이 정렬되어 있다는 것이며, 이로 인해 인덱스를 구성하는 칼럼의 순서는 매우 중요하다.만약 (A, B, C) 칼럼으로 구성된 인덱스가 있을 때, WHERE 절에 B와 C 칼럼에 대한 조건을 가지고 있다면 이 쿼리는 인덱스를 활용할 수 없다는 제약이 있

해시 조인 Hash Join MySQL 8.0.18 버전부터 추가로 지원되었다. MySQL 8.0.17 버전까지는 해시 조인 기능이 없었기 때문에, 조인 조건이 좋지 않은 경우 블록 네스티드 루프 조인(Block Nested Loop) 알고리즘을 사용했다. MySQL 8.0.18과 8.0.19 버전에서는 동등 조인(Equi-Join)을 위해서는 ...

인덱스 정렬 선호 IGNORE INDEX 힌트 MySQL 옵티마이저는 ORDER BY 또는 GROUP BY를 인덱스를 사용해 처리 가능한 경우, 쿼리의 실행 계획에서 이 인덱스의 가중치를 높이 설정해서 실행된다. 예를 들어, 다음 쿼리는 2가지 실행 계획을 선택할 수 있다. ixhiredate 인덱스를 이용해 WHERE 절 조건에 일치하는 레코...

쿼리 힌트 MySQL 서버가 부족한 실행 계획을 수립해야 할 경우, 옵티마이저에게 쿼리의 실행 계획을 어떻게 수립해야 할지 알려줄 수 있는 방법이 필요하다. 일반적인 RDBMS에서는 이런 목적으로 힌트가 제공된다. MySQL 서버에서 사용 가능한 쿼리 힌트는 다음 두 가지로 구분할 수 있다. 인덱스 힌트 옵타마이저 힌트 이 이외에도, 여기에...

STRAIGHT_JOIN STRAIGHT_JOIN 는 옵티마이저 힌트인 동시에 조인 키워드이기도 하다. 여러 개의 테이블이 조인될 때, 옵티마이저가 그때그때 각 테이블의 통계 정보와 쿼리의 조건을 기반으로 가장 최적이라고 판단되는 순서로 조인한다. 어느 테이블이 드라이빙 테이블이 되고, 어느 테이블이 드리븐 테이블이 될 지 알 수 없다. 일...

조인의 순서를 변경하는 것 다음으로 자주 사용된다.3~4개 이상의 칼럼을 포함하는 비슷한 인덱스가 여러 개 존재하는 경우, 옵티마이저가 가끔 실수를 하므로 강제로 특정 인덱스를 사용하도록 힌트를 추가한다.대체로 MySQL 옵티마이저는 어떤 인덱스를 사용해야 할지를 무난

성능 향상이 아닌, 개발자의 편의를 위해 만들어진 힌트다.MySQL의 LIMIT를 사용하는 경우, 조건을 만족하는 레코드가 LIMIT에 명시된 수보다 더 많다고 하더라도 LIMIT에 명시된 수만큼 만족하는 레코드를 찾으면 즉시 검색 작업을 멈춘다.하지만 SQL_CALC

옵티마이저 힌트 MAXEXECUTIONTIME 단순히 쿼리의 최대 실행 시간을 설정하는 힌트 옵티마이저 힌트 중 유일하게 쿼리의 실행 계획에 영향을 미치지 않는다. 밀리초 단위의 시간을 설정하며, 쿼리가 지정된 시간을 초과하면 쿼리는 실패한다. SET_VAR 옵티마이저 힌트뿐만 아니라 MySQL 서버의 시스템 변수들 또한 쿼리의 실행 계획에 상당한 ...

MySQL은 소스가 공개된 오픈소스 데이터베이스이다.1979년 스웨덴의 TcX라는 회사의 터미널 인터페이스 라이브러리인 UNIREG로부터 시작했다.UNIREG는 1994년 웹 시스템의 데이터베이스로 사용하기 시작하면서 MySQL 버전 1.0이 완성되었다.이는 TcX 시

들어가기 전에 macOS와 윈도우의 경우 앞서 설치 과정에서 설정 파일의 경로에 대해 살펴봤다. GUI로 MySQL 서버를 시작하거나 종료하는 것을 쉽게 제어할 수 있다. 리눅스 운영체제의 경우 리눅스 운영체제는 거의 대부분의 서비스 환경에서 사용된다. 이 글에

MySQL 서버 업그레이드 업그레이드 방식 MySQL 서버를 업그레이드하는 방법으로는 다음의 두 가지 방법이 있다. 인플레이스 업그레이드 (In-Place Upgrade) MySQL 서버의 데이터 파일을 그대로 두고 업그레이드 하는 방법 여러 가지 제약 사항이 있지만 업그레이드 시간을 크게 단축할 수 있다. 논리적 업그레이드 (Logic...

설정 파일 운영체제별 설정 파일 일반적으로 MySQL 서버는 단 하나의 설정 파일을 사용한다. 리눅스를 포함한 유닉스 계열에서는 “my.cnf”라는 이름을 사용한다. 윈도우 계열에서는 “my.ini”라는 이름을 사용한다. 설정 파일의 경로 설정 파일의 경로는 고정되어 있지 않다. 실제 MySQL 서버는 단 하나의 설정 파일(my.cnf)만 사용하지만...

MySQL에서 사용자 계정을 생성하는 방법이나 각 계정의 권한을 설정하는 방법은 다른 DBMS와는 조금 차이가 있다. > 사용자 식별 MySQL의 사용자는 다른 DBMS와는 조금 다르게 사용자의 계정뿐 아니라 사용자의 접속 지점도 계정의 일부가 된다. 사용자의 접속 지점: 클라이언트가 실행된 호스트명이나 도메인 또는 IP 주소 MySQL에서 계정...

시스템 계정과 일반 계정 > 💡 계정과 사용자 > 일반적으로 데이터베이스에서는 계정과 사용자라는 말을 혼용하는데, 이번 장에서는 설명과 편의를 위해 두 단어를 다음과 같이 구분해서 사용했다. > > * 사용자: MySQL 서버를 사용하는 주체 (사람 또는 응용프로그

MySQL 서버의 비밀번호는 다음 기능을 가지고 있다.유효기간이나 이력 관리를 통한 재사용 금지 기능비밀번호를 쉽게 유추할 수 있는 단어들이 사용되지 않게 글자의 조합을 강제하거나 금칙어를 설정하는 기능MySQL 서버에서 비밀번호의 유효성 체크 규칙을 적용하려면 val

MySQL 5.7 버전까지 권한은 글로벌 권한과 객체 단위의 권한으로 구분됐다.글로벌(Global) 권한 : 데이터베이스나 테이블 이외의 객체에 적용되는 권한객체 권한 : 데이터베이스나 테이블을 제어하는 데 필요한 권한글로벌 권한은 GRANT 명령에서 특정 객체를 명시

역할(Role) 역할이란 MySQL 8.0 버전부터 권한을 묶어서 역할(Role)을 사용할 수 있게 됐다. 실제 MySQL 서버 내부적으로 역할은 계정과 똑같은 모습을 하고 있다. MySQL 서버 내부적으로 역할과 계정은 동일한 객체로 취급된다. 단지 하나의 사용자 계정에 다른 사용자 계정이 가진 권한을 병합해서 권한 제어가 가능해졌을 뿐...

데이터 압축 데이터 파일의 크기 MySQL 서버에서 디스크에 저장된 데이터 파일의 크기는 일반적으로 쿼리의 처리 성능과도 직결되지만 백업 및 복구 시간과도 밀접하게 연결된다. 디스크의 데이터 파일이 크면 클수록 쿼리를 처리하기 위해서 더 많은 데이터 페이지를 InnoDB 버퍼 풀로 읽어야 할 수도 있고 새로운 페이지가 버퍼 풀로 적재되기 ...

테이블 압축은 운영체제나 하드웨어에 대한 제약 없이 사용할 수 있기 때문에 일반적으로 활용도가 더 높은 편이다.테이블 압축은 우선 디스크의 데이터 파일 크기를 줄일 수 있기 때문에 그만큼의 이득은 있다.버퍼 풀 공간 활용률이 낮음쿼리 처리 성능이 낮음빈번한 데이터 변경

MySQL 5.7 버전부터 데이터 암호화 기능이 지원됐다.처음에는 데이터 파일(테이블스페이스)에 대해서만 암호화 기능이 제공됐다.MySQL 8.0으로 업그레이드되면서 데이터 파일뿐만 아니라 리두 로그나 언두 로그, 복제를 위한 바이너리 로그 등도 모두 암호화 기능을 지

테이블 암호화 키링 플러그인은 마스터 키를 생성하고 관리하는 부분까지만 담당한다. 즉, 어떤 키링 플러그인을 사용하든 관계없이 암호화된 테이블을 생성하고 활용하는 방법은 모두 동일하다. 테이블 생성 TDE를 이용하는 테이블은 생성 시 마지막에 ENCRYPTION=

평문으로 저장되는 로그 테이블의 암호화를 적용해도 리두 로그나 언두 로그, 복제를 위한 바이너리 로그에는 평문으로 저장된다. 디스크로 저장되는 데이터만 암호화되고 MySQL 서버의 메모리에 존재하는 데이터는 복호화된 평문으로 관리된다. 평문 데이터가 데이터 파일 이외의 디스크 파일로 기록되는 경우에는 여전히 평문으로 저장된다. MySQL 8...

바이너리 로그와 릴레이 로그 파일 또한, 테이블 암호화가 적용돼도 평문을 저장한다.바이너리 로그는 의도적으로 상당히 긴 시간 동안 보관하는 서비스도 있고, 때로는 증분 백업(Incremental Backup)을 위해 바이너리 로그를 보관하기도 한다.이런 이유로 바이너리

통계 정보 MySQL 서버는 5.7 버전까지 테이블과 인덱스에 대한 개괄적인 정보를 가지고 실행 계획을 수립했다. 테이블 칼럼의 값들이 실제 어떻게 분포돼 있는지에 대한 정보가 없기 때문에 실행 계획의 정확도가 떨어지는 경우가 많았다. MySQL 8.0 버전부터는 인덱스되지 않은 칼럼들에 대해서도 데이터 분포도를 수집해서 저장하는 히스토그램(His...

MySQL 5.7 버전까지의 통계 정보는 단순히 인덱스된 칼럼의 유니크한 값의 개수 정도만 가지고 있었다.옵티마이저가 최적의 실행 계획을 수립하기에는 많이 부족했다.옵티마이저는 이러한 부족함을 메우기 위해 실행 계획을 수립할 때 실제 인덱스의 일부 페이지를 랜덤으로 가

코스트 모델 (Cost Model) MySQL 서버가 쿼리를 처리하려면 다음과 같은 다양한 작업을 필요로 한다. 디스크로부터 데이터 페이지 읽기 메모리(InnoDB 버퍼 풀)로부터 데이터 페이지 읽기 인덱스 키 비교 레코드 평가 메모리 임시 테이블 작업 디스크 임시 테이블 작업 MySQL 서버는 사용자의 쿼리에 ...

MySQL 서버의 실행 계획은 DESC 또는 EXPLAIN 명령으로 확인할 수 있다.MySQL 8.0 버전부터는 EXPLAIN 명령에 사용할 수 있는 새로운 옵션이 추가됐다.MySQL 8.0 버전부터는 모든 내용이 통합되어 보이도록 개선되었다.EXPLAIN의 EXTEN

실행 계획에 표시되는 각 컬럼이 어떤 것을 의미하고, 어떤 값이 출력되는지 살펴본다. > id 칼럼 단위 쿼리 하나의 SELECT 문장은 다시 1개 이상의 하위(SUB) SELECT 문장을 포함할 수 있다. 쿼리 문장을 SELECT 키워드 단위로 구분한 것을 “단위(SELECT) 쿼리”라고 표현한다. id 칼럼 실행 계획에서 가장 왼쪽에 표시된다...

각 단위 SELECT 쿼리가 어떤 타입의 쿼리인지 표시되는 칼럼이다.select_type 칼럼에 표시될 수 있는 값은 다음과 같다.

MySQL 서버의 실행 계획은 단위 SELECT 쿼리 기준이 아니라 테이블 기준으로 표시된다.테이블의 이름에 별칭이 부여된 경우에는 별칭이 표시된다.MySQL 옵티마이저는 두 번째 쿼리가 요청되면 “FROM DUAL” 부분을 제거하고 첫 번째 쿼리와 동일하게 변형해서

partitions 칼럼 파티션 실행 계획 확인 MySQL 5.7 버전까지는 옵티마이저가 사용하는 파티션들의 목록은 EXPLAIN PARTITION 명령을 이용해 확인 가능했다. MySQL 8.0 버전부터는 EXPLAIN 명령으로 파티션 관련 실행 계획까지 모두 확인할 수 있게 변경됐다. 파티션 프루닝 (Partition pruning) 다음과 같은...

type 칼럼 쿼리의 실행 계획에서 type 이후의 칼럼은 MySQL 서버가 각 테이블의 레코드를 어떤 방식으로 읽었는지를 나타낸다. 인덱스를 사용해 레코드를 읽었는지 풀 테이블 스캔으로 레코드를 읽었는지 일반적으로 쿼리를 튜닝할 때 인덱스를 효율적으로 사용하는지 확인하는 것이 중요하므로, type 칼럼은 반드시 체크해야 할 중요한 정보다....

인덱스(key) 관련 칼럼 possible_keys 칼럼 옵티마이저가 최적의 실행 계획을 만들기 위해 후보로 선정했던 접근 방법에서 사용되는 인덱스의 목록이다. “사용될 법했던 인덱스의 목록” 실제 실행 계획은 그 테이블의 모든 인덱스가 목록에 포함되어 나오는 경우가 허다하기에 쿼리를 튜닝하는데 크게 도움이 되지는 않는다. key 칼럼 최종 ...

ref 칼럼 참조 조건(Equal 비교 조건)으로 어떤 값이 제공됐는지 보여준다. 이 칼럼에 출력되는 값은 크게 신경 쓰지 않아도 무방하다. 상숫값을 지정했다면 ref 칼럼의 값은 const로 표시되고, 다른 테이블의 칼럼값이면 그 테이블명과 칼럼명이 표시된다. func 값 가끔 쿼리의 실행 계획에서 ref 칼럼의 값이 func 으로 표시될 때...

MySQL 옵티마이저는 각 조건에 대해 가능한 처리 방식을 나열하고, 각 처리 방식의 비용을 비교해 최종적으로 하나의 실행 계획을 수립한다.이때, 각 처리 방식이 얼마나 많은 레코드를 읽고 비교해야 하는지 예측해서 비용을 산정한다.대상 테이블에 얼마나 많은 레코드가 포

filtered 칼럼 옵티마이저는 각 테이블에서 일치하는 레코드의 개수를 가능하면 정확히 파악해야 좀 더 효율적인 실행 계획을 수립할 수 있다. rows 칼럼의 값은 인덱스를 사용하는 조건에만 일치하는 레코드를 건수를 예측한 것인데, 대부분 쿼리에서 WHERE 절에서 사용되는 조건이 모두 인덱스를 사용할 수 있는 것은 아니다. 특히 조인이 ...

Extra 칼럼 쿼리의 실행 계획에서 성능에 관련된 중요한 내용이 Extra 칼럼에 자주 표시된다. 주로 내부적인 처리 알고리즘에 대해 조금 더 깊이 있는 내용을 보여주는 경우가 많다. MySQL 서버의 버전이 업그레이드되고 최적화 기능이 도입될 수록 새로운 내용이 더 추가될 것으로 보인다. Extra 칼럼에는 고정된 몇 개의 문장이 표시된...

ORDER BY 처리가 인덱스를 사용하지 못할 때만 이 문구가 표시된다.조회된 레코드를 정렬용 메모리 버퍼에 복사해 퀵 소트 또는 힙 소트 알고리즘을 이용해 정렬을 수행한다는 의미이다.이 문구가 출력되는 쿼리는 많은 부하를 일으키므로 가능하다면 쿼리를 튜닝하거나 인덱스