[MySQL] RealMySQL 8.0 4.1 MySQL 엔진 아키텍처

참고 자료 

RealMySQL 8.0 1권 - 백은빈, 이성욱 지음

해당 글은 책에서 나오는 내용을 나중에 편하게 보기 위해서 요약한 내용이다. 

04장 아키텍처

MySQL 서버는 사람의 머리 역할을 하는 MySQL 엔진과 손발 역할을 담당하는 스토리지 엔진으로 구분할 수 있다.

스토리지 엔진은 핸들러 API를 만족하면 누구든지 스토리지 엔진을 구현해서 MySQL 서버에 추가해서 사용할 수 있다.

MySQL 엔진, MySQL 서버에서 기본으로 제공하는 InnoDB 스토리지 엔진,  MyISAM 스토리지 엔진에 대해서 알아보자 

4.1 MySQL 엔진 아키텍처

그림 4.1 MySQL 서버의 전체 구조

 

MySQL 접근 방법 지원

MySQL은 일반 사용 RDBMS와 같이 대부분의 프로그래밍 언어로부터 접근 방법을 모두 제공한다.

JDBC, ODBC, .NET의 표준 드라이버를 제공하며 이러한 드라이버를 이용해 C/C++, .PHP, JAVA, ... 모든 언어로 MySQL 서버에서 쿼리를 사용할 수 있게 지원한다.

4.1.1.1 MySQL 엔진 

MySQL 엔진은 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기

쿼리의 최적화된 실행을 위한 옵티마이저로 구성된다. 

 

MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행이 가능하다.

4.1.1.2 스토리지 엔진 

MySQL 엔진은 요청된 SQL 문장을 분석하거나 최적화하는 등 DBMS의 두뇌에 해당하는 역할을 한다. 

실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽는 행위는 스토리지 엔진이 담당한다. 

 

MySQL 서버에서 MySQL 엔진은 하나지만 스토리지 엔진은 동시에 n개를 사용할 수 있다. 

 

테이블 생성과 스토리지 엔진 지정 예제

CREATE TABLE test_table (fd1 INT, fd2 INT) ENGINE=INNODB;

테이블이 사용할 스토리지 엔진을 InnoDB로 지정 

이후 해당 테이블의 모든 읽기 작업이나 변경은 InnoDB 엔진이 처리한다. 

 

각 스토리지 엔진은 성능 향상을 위해서 키 캐시(MyISAM 스토리지 엔진)과
InnoDB 버퍼 풀(InnoDB 스토리지 엔진) 같은 기능을 내장하고 있다. 

4.1.1.3 핸들러 API

MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때 각 스토리지 엔진에 쓰기 또는 읽기를 요청한다. 

이러한 요청을 핸들러(Handler) 요청이라 한다. 

여기에 사용되는 API를 핸들러 API 라고 한다. 

 

데이터 작업 확인 실행 숫자 확인 예제 

 SHOW GLOBAL STATUS LIKE 'Handler%';

4.1.2 MySQL 스레딩 구조 

 

MySQL 서버는 프로세스 기반이 아닌 스레드 기반으로 작동한다. 

크게 포그라운드(Foreground) 스레드, 백그라운드(Background) 스레드로 구분한다.

 

MySQL 서버에서 실행중인 스레드 목록 확인 예제 

performance_schema 데이터베이스의 threads 테이블을 통해서 확인할 수 있다. 

select thread_id, name, type, processlist_user, processlist_host 
from performance_schema.threads 
order by type, thread_id;

총 39개의 스레드가 실행 중 (select count(*) from threads: result 39)

그중에서 36개가 백그라운드 스레드이고 나머지 3개만 포그라운드 스레드이다.

이 중에서 마지막 thread/sql/one-connection 스레드만 실제 사용자의 요청을 처리하는 포그라운드 스레드다. 

백그라운드 스레드의 개수는 MySQL 서버의 설정에 따라 가변적이다. 

동일한 이름의 스레드가 2개 이상씩 보이는 것은 MySQL 서버 설정 내용에 의해 여러 스레드가 동일 작업을 병렬로 처리하는 경우다.

ex) thread/innodb/io_read_thread

 

스레드 모델 

책에서 설명하는 스레드 모델은 MySQL 서버가 전통적으로 가지고 있던 스레드 모델이다.

즉 MySQL 커뮤니티 에디션에서 사용되는 모델이다. 

MySQL 엔터프라이즈 에디션(유료), Percona MySQL 서버에서는 전통적인 스레드 모델이 아닌 스레드 풀(Thread Pool) 모델을 사용할 수도 있다. 

 

스레드 풀 VS 전통적인 스레드 모델 

두 모델의 차이점은 포그라운드 스레드와 커넥션의 관계이다. 

전통적인 스레드 모델에서는 포그라운드 스레드와 커넥션이 1:1 관계다. 

스레드 풀에서는 포그라운드 스레드와 커넥션이 1:N이다. 

즉, 1개의 포그라운드 스레드가 여러 커넥션 요청을 담당한다. 

4.1.2.1 포그라운드 스레드(클라이언트 스레드 = 유저 스레드)

포그라운드 스레드는 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다. 

또한 최소 MySQL 서버에 접속한 클라이언트의 수만큼 존재한다.

클라이언트 사용자가 작업을 마치고 커넥션을 종료하면 해당 커넥션을 담당했던 스레드는 다시 스레드 캐시(Thread Cache)로 돌아간다. 

이미 캐시에 일정 개수 이상의 대기 중인 스레드가 있으면 스레드 캐시에 넣지 않고 스레드를 종료시켜

일정 개수의 스레드만 캐시에 존재하게 한다. 

스레드 캐시에 유지할 수 있는 최대 스레드는 thread_cache_size 시스템 변수로 설정한다. 

 SHOW VARIABLES LIKE 'thread_cache_size';

 

스프링 애플리케이션 

스프링 부트 2.0 이상부터 커넥션 풀을 히카리 커넥션 풀을 default로 사용한다. 

히카리 커넥션 풀은 개발자가 설정한 개수의 커넥션을 미리 생성하는데 생성된 커넥션은 애플리케이션이 종료될 때까지 

유지한다. 

그렇다면 MySQL 서버의 포그라운드 스레드 개수는 히카리 풀의 스레드 개수 설정과 마찬가지로 포그라운드 스레드 개수를 유지할 것이다. 히카리 풀을 사용하면 커넥션을 종료하지 않고 재사용하니까!! 

 

MyISAM, InnoDB 데이터 처리 스레드 

포그라운드 스레드는 데이터를 MySQL의 데이터 버퍼나 캐시에서 가져오며, 버퍼나 캐시에 데이터가 없는 경우

직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리한다. 

MyISAM 테이블은 디스크 쓰기 작업까지 포그라운드 스레드가 처리하지만 InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고 버퍼에서 디스크까지 기록하는 작업은 백그라운드 스레드가 처리한다. 

4.1.2.2 백그라운드 스레드

MyISAM의 경우에는 별로 해당 사항이 없다.

하지만 InnoDB는 다음과 같이 여러 가지 작업이 백그라운드로 처리된다. 

 

백그라운드 스레드 종류 

인서트 버퍼(Insert Buffer)를 병합하는 스레드 

로그를 디스크에 기록하는 스레드(Log Thread)

InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드 (Write Thread)

데이터를 버퍼로 읽어 오는 스레드 

잠금이나 데드락을 모니터링하는 스레드 

 

데이터의 쓰기 스레드 / 읽기 스레드 개수 지정 

innodb_write_io_threads, innodb_read_io_threads 시스템 변수로 스레드의 개수를 설정한다. 

 

InnoDB에서도 데이터를 읽는 작업은 주로 포그라운드 스레드에서 처리되기 때문에 읽기 스레드는 많이 설정할 필요는 없지만 쓰기 스레드는 아주 많은 작업을 백그라운드로 처리하기 때문에 일반적인 내장 디스크를 사용할 때는 2~4 정도, DAS나 SAN 같은 스토리지를 사용할 때는 디스크를 최적으로 사용할 수 있을 만큼 충분히 설정하는 것이 좋다.

사용자의 요청을 처리하는 도중 데이터의 쓰기 작업은 지연되어 처리될 수 있지만 읽기 작업은 절대 지연될 수 없다. 

그래서 InnoDB는 대부분 쓰기 작업을 버퍼링해서 일괄 처리하는 기능이 있다. 

하지만 MyISAM은 그렇지 않다 클라이언트 스레드가 쓰기 작업까지 함께 처리하도록 설계돼 있으니 일반적인 쿼리는 쓰기 버퍼링 기능을 사용할 수 없다. 

4.1.3 메모리 할당 및 사용 구조 

MySQL에서 사용하는 메모리 공간은 글로벌 메모리 영역과 로컬 메모리 영역으로 구분된다.

글로벌 메모리 영역의 모든 메모리 공간은 MySQL 서버가 시작되면서 운영체제로부터 할당된다.

이때 요청된 메모리를 100% 할당해줄 수도 있고, 필요할 때 조금씩 할당해주는 경우도 있다.

단순하게 MySQL 시스템 변수로 설정해 둔 만큼 운영체제로부터 메모리를 할당받는다고 생각하면 된다.

글로벌 메모리 영역과 로컬 메모리 영역은 MySQL 서버 내에 존재하는 많은 스레드가 공유해서 사용하는지 여부에 따라 구분된다. 

4.1.3.1 글로벌 메모리 영역

클라이언트 스레드의 수와 무관하게 메모리 공간이 할당된다. (일반적으로 하나)

필요에 따라 2개 이상의 할당받을 수 있지만 스레드 수와는 무관하며, 모든 스레드에 의해 공유된다.

 

테이블 캐시

InnoDB 버퍼 풀 

InnoDB 어댑티브 해시 인덱스

InnoDB 리두 로그 버퍼

4.1.3.2 로컬 메모리 영역(클라이언트 메모리 영역)

세션, 커넥션 메모리 영역이라고도 표현한다.

 MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역이다. 

대표적으로 커넥션 버퍼, 정렬 버퍼 등이 있다. 

로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되어 사용하지 않는 특징이 있다.

 

로컬 메모리 영역 설정 

일반적으로 글로벌 메모리의 영역은 주의해서 크기를 설정하지만 정렬 버퍼와 같은 로컬 메모리 영역은 신경 쓰지 않고 설정한다. 최악의 경우 MySQL 서버가 메모리 부족으로 멈춰 버릴 수도 있으니 적절한 메모리 공간을 설정하자.

 

메모리 할당 특징 

로컬 메모리 공간은 커넥션이 열려 있는 동안 계속 할당되는 (커넥션 버퍼, 결과 버퍼)도 있고 쿼리를 실행하는 순간에만 할당했다가 다시 해제하는 공간(소트 버퍼, 조인 버퍼)도 있다.

각 쿼리의 용도별로 필요할 때만 메모리 공간을 할당하고 필요하지 않은 경우 메모리 공간을 할당하지 않을 수도 있다.

ex) 소트 버퍼, 조인 버퍼 같은 공간 

그냥 쉽게 생각해서 글로벌 메모리 영역은 MySQL 서버(프로그램, 프로세스)가 할당받는 각 스레드가 공유하는 영역이고 
로컬 메모리 영역은 MySQL 서버의 각 스레드가 독립적으로 할당받는 영역이라고 이해하면 편하다.

 

대표적인 로컬 메모리 영역 

정렬 버퍼(Sort Buffer)

조인 버퍼 

바이너리 로그 캐시 

네트워크 버퍼 

4.1.4 플러그인 스토리지 엔진 모델 

 

MySQL 독특한 구조 중 대표적인 것이 플러그인 모델이다. 

플러그인해서 사용할 수 있는 것은 스토리지 엔진만 있는 것은 아니다.

 

ex) 사용자의 인증을 위한 Native Authentication, Caching SHA-2 Authentication 제공

 

MySQL 엔진과 스토리지 엔진 

 

MySQL은 기본적으로 많은 스토리지 엔진을 기본적으로 제공한다.

하지만 부가적인 기능을 제공하는 스토리지 엔진이 필요하면 직접 개발하는 것도 가능하다. 

그림 4.5 처럼 새로운 용도의 스토리지 엔진을 만든다 하더라도 DBMS의 일부분 기능만 수행하는 엔진을 작성하게 된다는 점을 기억하자 

 

MySQL 핸들러 

MySQL 엔진은 스토리지 엔진을 조정하기 위해 핸들러(Handler)라는 것을 사용하게 된다.

MySQL 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통해야 한다.

나중에 MySQL 서버의 상태 변수를 배울 텐데 이런 상태 변수 가운데 'Handler_'로 시작하는 것이 많다. 

MySQL에서 MyISAM이나 InnoDB 같이 다른 스토리지 엔진을 사용하는 테이블에 대해 쿼리를 실행하더라도 MySQL 처리 내용은 대부분 동일하다 그림4.5의 데이터 읽기/쓰기 부분만 차이가 있을 뿐이다. 

실질적인 GROUP BY, ORDER BY 같은 복잡한 연산은 스토리지 엔진이 아닌 MySQL 엔진의 처리 영역인 쿼리 실행기에서 처리한다.

 

MySQL 서버에서 지원하는 엔진 조회하기 예제 

SHOW ENGINES;

 

YES

MySQL 서버에 해당 스토리지 엔진이 포함돼 있고, 사용 기능으로 활성화된 상태 

 

DEFAULT

'YES' 와 동일한 상태지만 필수 스토리지 엔진임을 의미한다

이 스토리지 엔진이 없으면 MySQL 서버가 시작되지 않을 수도 있음을 의미한다 

 

NO

현재 MySQL 서버에 포함되지 않았음을 의미한다

 

DISABLED

현재 MySQL 서버에 해당 스토리지 엔진이 포함됐지만 파라미터에 의해 비활성화된 상태다

MySQL 서버에 포함되지 않은 스토리지 엔진(Support 칼럼 NO)를 사용하려면 MySQL 서버를 다시 빌드(컴파일)해야 한다.

만약 스토리지 엔진이 플러그인 형태로 빌드되어 있다면 다운로드해서 끼워 넣기만 하면 사용할 수 있다. 

 

모든 플러그인 확인 예제 

SHOW PLUGINS;

4.1.5 컴포넌트 

MySQL8.0 부터는 기존의 플러그인 아키텍처를 대체하기 위해 컴포넌트 아키텍처가 지원된다.

 

플러그인 단점

플러그인은 오직 MySQL 서버와 인터페이스 할 수 있고 플러그인끼리 통신할 수 없음

플러그인은 MySQL 서버의 변수나 함수를 직접 호출하기 때문에 안전하지 않음(캡슐화 X)

플러그인은 상호 의존 관계를 설정할 수 없어서 초기화가 어려움 

 

비밀번호 검증 기능 

MySQL5.7 까지 비밀번호 검증 기능은 플러그인 형태로 제공됐지만 MySQL8.0 부터 컴포넌트로 개선됐다.

 

현재 설치된 컴포넌트 확인 예제 

SELECT * FROM mysql.component;

4.1.6 쿼리 실행 구조 

4.1.6.1 쿼리 파서 

쿼리 파서는 사용자 요청으로 들어온 쿼리 문장을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)으로 분리해 

트리 형태의 구조로 만들어 내는 작업을 한다. 

쿼리 문장의 기본 문법 오류는 이 과정에서 발견되고 사용자에게 오류 메시지를 전달하게 된다.

4.1.6.2 전처리기 

파서 과정에서 만들어진 파서 트리를 기반으로 쿼리 문제에 구조적인 문제점이 있는지 확인한다.

각 토큰을 테이블 이름, 칼럼 이름, 내장 함수와 같은 객체를 매핑해 객체의 존재 여부와 접근 권한을 확인한다. 

실제 존재하지 않거나 권한상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러진다.

4.1.6.3 옵티마이저

옵티마이저는 DBMS 두뇌에 해당한다.

사용자의 요청으로 온 쿼리 문장을 어떻게 가장 저렴한 비용으로 빠르게 처리할지를 결정하는 역할을 담당한다. 

4.1.6.4 실행 엔진 = 쿼리 실행기 

옵티마이저가 두뇌라면 실행 엔진과 핸들러는 손과 발에 비유할 수 있다.

 

실행 엔진이 하는 일을 에제로 이해해 보자 

옵티마이저가 GROUP BY를 처리하기 위해서 임시 테이블을 사용하기로 결정 예시 

 

1. 실행 엔진이 핸들러에게 임시 테이블을 만들라고 요청

2. 실행 엔진은 WHERE 절에 일치하는 레코드를 핸들러에게 요청 

3. 읽어온 레코드를 1번에 준비한 임시 테이블로 저장하라고 핸들러에게 요청 

4. 데이터가 준비된 임시 테이블에서 필요한 방식으로 데이터를 읽어 오라고 핸들러에게 요청 

5. 최종적으로 실행 엔진은 결과를 사용자나 다른 모듈에 넘긴다. 

 

실행 엔진은 옵티마이저가 만들어준 계획을 바탕으로 각 핸들러(스토리지 엔진)에게 요청해서 받은 결과를 다른 핸들러 요청의 입력으로 연결하는 역할을 수행한다. 

4.1.6.5 핸들러(스토리지 엔진)

MySQL 서버의 가장 밑단에서 MySQL 실행 엔진의 요청에 따라 데이터를 디스크에 read/write 역할을 담당한다.

MyISAM 테이블을 조작하는 경우 핸들러가 MyISAM 스토리지 엔진 InnoDB 테이블을 조작하는 경우 핸들러가 InnoDB 스토리지 엔진이 된다. 

4.1.8 쿼리 캐시 

MySQL 서버에서 쿼리 캐시(Query Cache)는 SQL의 실행 결과를 메모리에 캐시하고, 동일 SQL 쿼리가 실행되면

테이블을 읽지 않고 즉시 결과를 반환하기 때문에 매우 빠른 성능을 보였다.

 

하지만 테이블의 데이터가 변경되면 캐시에 저장된 결과 중에서 변경된 테이블과 관련된 것들은 모두 삭제해야 했다.

이는 삼각한 동시 처리 성능 저하를 유발한다. 

 

MySQL 8.0이 되면서 쿼리 캐시는 MySQL 서버의 기능에서 완전히 제거되었다.

4.1.9 스레드 풀(Thread Pool)

 MySQL 서버 엔터프라이즈 에디션은 스레드 풀 기능을 (내장 형태)로 제공하지만 MySQL 커뮤니티 에디션은 지원하지 않는다.

여기서는 엔터프라이즈 에디션(유료 버전)의 스레드 풀이 아닌 Percona Server에서 제공하는 스레드 풀 기능을 설명 

 

커뮤니티 에디션에서 스레드 풀 사용 

Percona Server 스레드 풀은 플러그인 형태로 작동된다. 

만약 MySQL 커뮤니티 에디션에서 스레드 풀 기능을 사용하고 싶으면 동일 버전의 Percona Server에서 스레드 풀 라이브러리인(thread_pool.so 파일)를 MySQL 서버에 설치(INSTALL PLUGIN)해서 사용하면 된다.

 

스레드 풀 주의점 

스레드 풀은 사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요청이 많다 하더라도 MySQL 서버의

CPU가 제한된 개수의 스레드 처리에만 집중할 수 있게 해서 서버의 자원 소모를 줄이는 것이 목적이다.

하지만 이는 스케줄링 과정에서 CPU 점유 시간을 확보하지 못하는 경우에는 쿼리 처리 속도가 더 느려지는 사례가 발생할 수 있다. 

물론 적절한 숫자의 스레드만으로 CPU가 처리하도록 적절히 유도하면 CPU 프로세서 친화도(Processor affinity)도 높이고 불필요한 컨텍스트 스위칭을 줄여서 오버헤드를 낮출 수 있다. 

 

스레드 풀 설정 

Percona Server 스레드 풀은 기본적으로 CPU 코어 개수만큼 스레드 그룹을 생성한다. 

스레드 그룹의 개수는 thread_pool_size 시스템 변수를 변경해서 조정할 수 있다. 

일반적으로 CPU 코어의 개수와 맞추는 것이 CPU 프로세서 친화도를 높이는 데 좋다.

 

MySQL 서버는 요청을 스레드 풀로 처리를 이관해서 처리한다. 

만약 이미 스레드 풀이 처리 중인 작업이 있으면 thread_pool_oversubscribe 시스템 변수(기본 3)에 설정된 개수만큼 추가로 더 받아들여서 처리한다. 

이 값이 너무 크면 스케줄링 할 스레드가 많아지니 주의하자 

 

스레드 그룹의 모든 스레드가 일을 처리하고 있다면 스레드 풀은 스레드 그룹에 새로운 작업 스레드(Worker Thread)를 추가할지, 아니면 기존 작업 스레드가 처리를 완료할 때까지 가디릴지 여부를 판단해야 한다.

스레드 풀의 타이머 스레드는 주기적으로 스레드 그룹의 상태를 체크해서 therad_pool_stall_linit 시스템 변수에 정의된 시간만큼 작업 스레드가 지금 처리 중인 작업을 끝내지 못하면 스레드를 생성해서 그룹에 추가한다.

이때 전체 스레드 풀에 있는 스레드 개수는 thread_pool_max_threads 시스템 변수에 설정된 개수를 넘어설 수 없다. 

응답 시간이 아주 민감한 서비스는 therad_pool_stall_linit 시스템 변수를 낮춰서 사용하자

하지만 thread_pool_stall_limit가 0에 가깝다면 스레드 풀을 사용하지 않는 편이 나을 것이다. 

 

Percona Server 스레드 풀 선/후순위 큐

특정 트랜잭션이나 쿼리를 우선적으로 처리할 수 있는 기능을 제공한다. 

먼저 시작된 트랜잭션 내에 속한 쿼리를 빨리 처리해주면 해당 트랜잭션이 가지고 있는 잠금이 빨리 해제되어 전체적인 처리 성능을 향상시킬 수 있다.

 

유입된 요청 순서 

A(BEGIN), B(BEGIN), C(BEGIN), A(QUERY), B(QUERY), C(QEURY), A(COMMIT), B(COMMIT), C(COMMIT)

 

선순위 후순위 큐로 재배치 이후 처리 순서 

A(BEGIN), B(BEGIN), C(BEGIN), A(QUERY), A(COMMIT), B(QUERY), B(COMMIT), C(QEURY), C(COMMIT)

4.1.10 트랜잭션 지원 메타데이터 

메타데이터 

데이터베이스 서버에서 테이블의 구조 정보, 스토어드 프로그램 등의 정보를 데이터 딕셔너리 또는 메타데이터라고 한다. 

 

기존 관리 방식의 문제점 

MySQL 5.7 까지는 테이블의 구조를 FRM 파일에 저장하고 스토어드 프로그램 또한 (*.TRN, *TRG, *PAR) 기반으로 관리했다. 

이런 파일 기반의 메타데이터 관리는 트랜잭션을 지원하지 않아 테이블 생성 또는 변경 도중 MySQL 서버가 비정상적으로 종료되면 일관되지 않은 상태로 남는 문제가 있었다. 

 

문제점 개선 (트랜잭션 지원 메타데이터)

MySQL 8.0 부터는 이런 문제점을 해결하기 위해서 메타 데이터를 모두 InnoDB 테이블에 저장하도록 개선했다.

MySQL 서버가 작동하는 데 기본적으로 필요한 테이블을 묶어서 시스템 테이블이라고 한다. (ex: 사용자 인증 관련)

이 또한 InnoDB 테이블에 저장하도록 개선했다.  

 

시스템 테이블 + 데이터 딕셔너리(메타데이터) 정보를 mysql DB에 저장하고 있다.

mysql DB는 통째로 mysql.ibd 이름의 테이블스페이스에 저장된다. 

MySQL 서버의 데이터 디렉토리에 존재하는 mysql.ibd와 다른 *.ibd 파일을 주의하자

 

mysql DB 테이블 조회 결과 

데이터 딕셔너리를 저장하는 테이블이 있다고 하는데 조회가 불가능하다.

이는 사용자가 임의로 수정하지 못하게 사용자의 화면에 보여주지 않을 뿐 실제로 테이블은 존재한다.

대신 information_schema DB의 TABLES, COLUMS 등과 같은 뷰를 통해 조회할 수 있게 하고 있다.

SELECT TABLE_NAME, TABLE_TYPE, TABLE_SCHEMA
FROM information_schema.TABLES;

SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT
FROM information_schema.COLUMNS;

 

직접 조회: 접근이 거절됨 

mysql> SELECT * FROM mysql.tables;
ERROR 3554 (HY000): Access to data dictionary table 'mysql.tables' is rejected.

 

다른 스토리지 엔진 

MySQL 서버에서 InnoDB 스토리지 엔진을 사용하는 테이블은 메타 정보가 InnoDB 테이블 기반의 딕셔너리에 저장되지만 MyISAM이나 CSV 같은 스토리지 엔진은 SDI 파일을 사용한다. 

SDI는 직렬화(Serialized)를 위한 포맷으로 InnoDB 테이블들의 구조도 SDI 파일로 변환할 수 있다.