MySQL 기술 내부자 InnoDB 스토리지 엔진 연구 노트 1 장 MySQL 아키텍처 및 스토리지 엔진

MySQL은 거의 모든 운영 체제에서 실행할 수 있습니다. 다양한 시스템의 하단 구현 (예 : 스레드)이 다르지만 MySQL은 각 플랫폼에서 물리적 아키텍처의 일관성을 거의 보장 할 수 있습니다.

용어 :
1. 데이터베이스 : 물리적 운영 체제 파일 또는 기타 파일 유형의 모음입니다. MySQL 데이터베이스 파일은 frm, myd, myi 및 ibd로 끝나는 파일 일 수 있습니다. NDB를 사용할 때 데이터베이스 파일은 운영 체제의 파일이 아니라 메모리에 저장된 파일 일 수 있습니다.
2. 데이터베이스 인스턴스 : 데이터베이스 백그라운드 프로세스 / 스레드와 공유 메모리 영역으로 구성되며, 공유 메모리 영역은 백그라운드 프로세스 / 스레드를 실행하여 공유 할 수 있습니다. 데이터베이스 파워는 실제로 데이터베이스 파일을 조작하는 데 사용됩니다.

MySQL의 인스턴스와 데이터베이스는 일반적으로 일대일 대응이지만 클러스터의 경우 여러 인스턴스에서 데이터베이스를 사용할 수 있습니다.

MySQL은 SQLserver와 유사하지만 Oracle 다중 프로세스 아키텍처와는 다른 단일 프로세스 다중 스레드 아키텍처를 가진 데이터베이스입니다 (그러나 Oracle의 Windows 버전은 단일 프로세스 다중 스레드 아키텍처이기도합니다).

MySQL 프로세스가 시작되었는지 확인하십시오.

ps -ef | grep mysqld

인스턴스를 시작할 때 MySQL은 구성 파일을 읽고 매개 변수에 따라 데이터베이스 인스턴스를 시작합니다. 이는 oracle 매개 변수 파일 (spfile)과 유사하지만 Oracle에 매개 변수 파일이없는 경우 매개 변수 파일을 묻는 메시지가 표시됩니다. 찾을 수없고 시작에 실패 함 MySQL에는 구성 파일이 없으며 컴파일 중에 기본 매개 변수 설정에 따라 인스턴스가 시작됩니다.

MySQL이 구성 파일을 읽는 위치를 확인합니다.

mysql --help | grep my.cnf

실행 :
여기에 사진 설명 삽입
MySQL은 위에 나열된 순서대로 처음부터 끝까지 구성 파일을 읽습니다. 여러 구성 파일에 동일한 매개 변수가있는 경우 매개 변수의 마지막 항목이 우선합니다.

Linux에서 구성 파일은 일반적으로 /etc/my.cnf에 있으며 Windows에서 구성 파일의 접미사는 .cnf 또는 .ini 일 mysql -help수 있습니다. 또한 Windows에서 실행할 때 구성 파일의 읽기 위치를 찾을 수도 있습니다.

구성 파일에 데이터베이스의 경로를 지정하는 datadir 매개 변수가 있습니다. Linux에서이 매개 변수의 기본값은 /usr/local/mysql/data입니다. 현재 datadir 경로를 확인하십시오.

SHOW VARIABLES LIKE 'datadir'\G;

실행 :
여기에 사진 설명 삽입

\ G의 기능은 결과를 행에 세로로 표시하는 것입니다.

사용자 (디렉터리 소유자는 mysql) 및 datadir의 권한이 보장되어야하며 mysql 사용자 및 그룹 만 액세스 할 수 있습니다.

MySQL의 경우 데이터베이스는 특정 데이터 모델에 따라 구성되고 보조 저장소 (예 : 하드 디스크, CD)에 저장되는 데이터 모음입니다. 데이터베이스 인스턴스는 응용 프로그램이며 데이터베이스 데이터에 대한 모든 사용자 작업은 다음을 통해 완료됩니다. 데이터베이스 인스턴스.

여기에 사진 설명 삽입
위 그림에서 MySQL은 다음과 같은 부분으로
구성됩니다. 1. 연결 풀 구성 요소.
2. 관리 서비스 및 도구 구성 요소.
3. SQL 인터페이스 구성 요소.
4. 쿼리 분석기 구성 요소.
5. 최적화 프로그램 구성 요소.
6. 캐시 구성 요소.
7. 플러그인 스토리지 엔진.
8. 실제 파일.

스토리지 엔진은 데이터베이스가 아닌 테이블을 기반으로합니다.

MySQL의 플러그인 스토리지 엔진은 일련의 표준 관리 및 서비스 지원을 제공합니다. 이러한 표준은 스토리지 엔진 자체와는 아무 관련이 없으며 스토리지 엔진은 기본 물리적 구조의 실현 일뿐입니다.

각 스토리지 엔진에는 고유 한 특성이 있으며 특정 애플리케이션에 따라 서로 다른 스토리지 엔진 테이블이 설정됩니다. 개발자에게 스토리지 엔진은 투명하지만 개발자는 서로 다른 스토리지 엔진의 차이점을 이해하는 것이 좋습니다.

MySQL은 오픈 소스입니다. MySQL의 사전 정의 된 스토리지 엔진 인터페이스를 기반으로 자체 스토리지 엔진을 작성하거나 만족스럽지 않은 특정 스토리지 엔진의 소스 코드를 수정할 수 있습니다.

스토리지 엔진은 공식 스토리지 엔진과 타사 스토리지 엔진으로 나뉩니다. InnoDB는 타사 스토리지 엔진으로 시작되었습니다. Oracle이 인수했으며 현재 OLTP (온라인 트랜잭션 처리) 애플리케이션에서 가장 널리 사용되는 스토리지 엔진입니다.

InnoDB는 주로 OLTP 애플리케이션을위한 트랜잭션을 지원하며 행 잠금 설계, 외래 키 지원, Oracle과 유사한 비 잠금 읽기를 지원합니다.

InnoDB는 논리적 테이블 스페이스에 데이터를 저장하고 MySQL 4.1부터는 각 InnoDB 스토리지 엔진 테이블을 별도의 ibd 파일에 저장할 수 있습니다. Oracle과 마찬가지로 InnoDB는 원시 장치를 사용하여 테이블 스페이스를 생성 할 수 있습니다.

InnoDB는 다중 버전 동시성 제어 (MVCC)를 사용하여 높은 동시성을 달성하고 SQL 표준의 4 가지 격리 수준을 구현합니다. 기본값은 반복 읽기 (REPEATABLE READ)입니다. 표준 SQL과 달리 InnoDB는 REPEATABLE READ 트랜잭션 격리 수준에 있습니다. Next-Key Lock 알고리즘을 사용하면 팬텀 읽기 생성을 어느 정도 피할 수 있습니다. InnoDB는 또한 삽입 버퍼링, 보조 쓰기, 적응 형 해시 인덱싱 및 사전 읽기와 같은 고성능 기능을 제공합니다.

InnoDB 테이블의 데이터 저장소는 Oracle의 IOT (Index Organized Table)와 유사한 집계 방법을 사용합니다. 각 테이블의 저장소는 기본 키 순서로 저장됩니다. 테이블을 정의 할 때 기본 키를 명시 적으로 지정하지 않으면 InnoDB는 기본 키로 각 ​​행에 대해 6 바이트 ROWID를 생성합니다.

MyISAM은 MySQL에서 공식적으로 제공하는 스토리지 엔진으로 트랜잭션을 지원하지 않고 테이블 잠금 및 전체 텍스트 인덱싱을 지원하며 OLAP (Online Analytical Processing) 작업 속도가 빠릅니다.

MyISAM 테이블은 MYD와 MYI로 구성됩니다. MYD는 데이터 파일을 저장하고 MYI는 인덱스를 저장합니다. 데이터 파일은 myisampack 도구로 추가로 압축 할 수 있습니다.이 도구는 Huffman 인코딩을 사용하여 데이터를 압축하므로 압축 된 테이블은 읽기 전용입니다. 이 도구는 데이터 파일의 압축을 풉니 다.

MySQL 5.0 이전에는 MyISAM이 기본적으로 4G 테이블을 지원합니다. 4G보다 큰 MyISAM 테이블을 지원해야하는 경우 MAX_ROWS 및 AVG_ROW_LENGTH 속성을 지정해야합니다. MySQL 5.0부터 MyISAM은 기본적으로 256T 단일 테이블 데이터를 지원합니다.

MyISAM 테이블의 경우 MySQL은 인덱스 파일 만 캐시하고 데이터 파일 캐시는 운영 체제 자체에서 수행합니다. 이는 LRU (Least Recent Used) 알고리즘을 사용하여 데이터를 캐시하는 대부분의 데이터베이스와 다릅니다. MySQL 5.1.23 이전에는 32 비트 또는 64 비트 시스템에 관계없이 캐시 인덱스의 최대 버퍼 크기를 4G로만 설정할 수 있습니다. 이후 버전에서는 64 비트 시스템이 4G보다 큰 인덱스 버퍼를 지원할 수 있습니다.

MySQL AB는 위 그림의 Cluster 엔진 인 Sony Ericsson에서 NDB 클러스터 엔진을 인수했습니다. Oracle의 RAC 클러스터와 비슷하지만 Oracle RAC와는 다른 모든 것을 공유합니다. 구조는 공유 무 클러스터 아키텍처로 제공 할 수 있습니다. 높은 수준의 고 가용성. NDB의 특징은 모든 데이터가 메모리에 저장되고 (MySQL 5.1부터는 인덱스되지 않은 데이터를 디스크에 저장할 수 있음) 기본 키 검색 속도가 매우 빠르다는 것입니다. NDB 데이터 저장 노드를 추가하면 데이터베이스 성능이 선형 적으로 향상 될 수 있습니다. 향상.

NDB의 JOIN 작업은 스토리지 엔진 계층이 아닌 MySQL 데이터베이스 계층에서 완료되므로 복잡한 연결 작업에는 엄청난 네트워크 오버 헤드가 필요하고 쿼리 속도가 매우 느립니다.

메모리 저장소 엔진 (이전에는 HEAP 저장소 엔진이라고 함)은 데이터를 메모리에 저장합니다. 데이터베이스가 다시 시작되거나 충돌하면 테이블의 데이터가 사라집니다. 임시 데이터 및 차원 테이블을 데이터웨어 하우스에 저장하는 데 적합한 임시 테이블 (예 : 배우로 채워진 영화 테이블) 테이블의 배우 ID는 배우의 모든 정보가 아니며 배우 테이블은 차원 테이블입니다). 기본적으로 B + 트리 인덱스 대신 해시 인덱스를 사용합니다.

메모리 엔진은 매우 빠르지 만 테이블 잠금 만 지원하고 동시성 성능이 좋지 않으며 TEXT 및 BLOB 열 유형을 지원하지 않으며 고정 길이 필드 (char) 메서드에 가변 길이 필드 (varchar)를 저장합니다. 메모리 낭비 (해결책이 있습니다).

MySQL은 메모리 스토리지 엔진을 임시 테이블로 사용하여 쿼리의 중간 결과 집합을 저장합니다. 중간 결과 집합이 메모리 테이블의 용량 설정보다 크거나 중간 결과에 TEXT 또는 BLOB 열 유형 필드가 포함 된 경우 MySQL은 MyISAM 테이블로 변환하고 디스크에 저장하십시오. MyISAM 테이블은 데이터 파일을 캐시하지 않으므로 현재 임시 테이블의 성능이 저하됩니다.

아카이브 스토리지 엔진은 INSERT 및 SELECT 작업 만 지원합니다. MySQL 5.1부터는 인덱스를 지원합니다. zlib 알고리즘을 사용하여 데이터 행을 압축하고 저장합니다. 압축률은 일반적으로 최대 1:10으로 데이터 아카이브에 적합합니다. . 아카이브 엔진은 행 잠금을 사용하여 동시 삽입 작업을 구현하지만 트랜잭션에 안전한 저장소 엔진이 아닙니다. 설계 목표는 고속 삽입 및 압축 기능을 제공하는 것입니다.

Federated Storage Engine은 데이터를 저장하지 않으며 원격 MySQL 데이터베이스 서버의 테이블을 가리 킵니다. SqlServer의 연결된 서버 및 Oracle의 투명 게이트웨이와 유사하지만 Federated 엔진은 이기종 데이터베이스 테이블이 아닌 MySQL 데이터베이스 테이블 만 지원합니다.

Maria 스토리지 엔진이 새로 개발되었으며, 설계 목표는 MySQL 기본 스토리지 엔진 인 MyISAM 스토리지 엔진을 대체하는 것입니다. 개발자는 MySQL의 창립자 중 한 명이며 MyISAM의 후속 버전으로 간주 될 수 있습니다. 기능에는 데이터 및 인덱스 파일 캐싱, 행 잠금 설계, MVCC 기능 제공, 트랜잭션 및 비 트랜잭션 보안 옵션 지원, 더 나은 BLOB 문자 유형 처리 성능이 포함됩니다.

여기에 사진 설명 삽입
많은 스토리지 엔진은 트랜잭션을 지원하지 않습니다. 데이터베이스 원칙 책에서는 데이터베이스와 기존 파일 시스템의 가장 큰 차이점은 데이터베이스가 트랜잭션을 지원한다는 점이지만 MySQL은 모든 응용 프로그램에 트랜잭션이 필요하지 않다고 생각하므로 트랜잭션을 지원하지 않는 엔진이 있습니다.

MySQL에서 지원하는 스토리지 엔진보기 :

SHOW ENGINES;

실행 :
여기에 사진 설명 삽입
information_schema 아키텍처에서 ENGINES 테이블을 확인할 수도 있습니다 :
여기에 사진 설명 삽입
동일한 양의 데이터, 테이블 크기 : InnoDB> MyISAM> Archive.

MySQL 연결은 통신 할 연결 프로세스 및 데이터베이스 인스턴스입니다.

TCP / IP를 통해 MySQL에 연결할 때 일반 클라이언트와 MySQL 인스턴스는 서로 다른 서버에 있습니다.

mysql -h192.168.0.101 -u david -p

위의 예는 TCP / IP 연결 요청이 호스트 IP가 192.168.0.101 인 MySQL 인스턴스로 시작되었음을 나타냅니다.

TCP / IP를 통해 MySQL 인스턴스에 연결할 때 MySQL은 먼저 권한보기를 확인하여 요청하는 클라이언트 IP가 MySQL 인스턴스에 연결할 수 있는지 확인합니다.이보기는 mysql 라이브러리 아래에 있으며 테이블 이름은 user :
여기에 사진 설명 삽입
visible from 위의 표에서는 David가 모든 IP 세그먼트에서이 인스턴스에 연결할 수 있으며 비밀번호가 필요하지 않습니다. 위의 표는 각 네트워크 세그먼트에서 루트 사용자의 액세스 제어 권한을 보여줍니다.

Windows에서 통신해야하는 두 프로세스가 동일한 서버에있는 경우 명명 된 파이프를 사용할 수 있습니다. SQL Server가 설치된 후의 로컬 연결은 기본적으로 명명 된 파이프도 사용합니다. MySQL이 명명 된 파이프를 사용하는 경우 구성 파일에서 -enable-named-pipe 옵션을 활성화해야합니다. MySQL 4.1 이후 MySQL은 공유 메모리 연결 방법을 제공합니다. 구성 파일에 –shared-memory를 추가해야합니다. 클라이언트가 연결될 때 -protocol = memory 옵션도 사용해야합니다.

Linux 및 Unix에서는 Unix 도메인 소켓을 사용할 수 있습니다. 네트워크 프로토콜이 아니며 MySQL 클라이언트와 데이터베이스 인스턴스가 동일한 서버에있을 때만 사용할 수 있습니다. 소켓 파일의 경로는 구성 파일에서 지정할 수 있습니다. -socket = / tmp / mysql.sock과 같은 데이터베이스 인스턴스를 시작한 후 Unix 도메인 소켓 파일을 확인합니다.

SHOW VARIABLES LIKE 'socket';

실행 :
여기에 사진 설명 삽입

도메인 소켓 파일의 경로를 알고 나면 다음과 같은 방법으로 연결할 수 있습니다.

mysql -udavid -S /tmp/mysql.sock

추천

출처blog.csdn.net/tus00000/article/details/111933999