mysql innodb가 뭐야?-MySQL 튜토리얼-php.cn

InnoDB는 MySQL의 데이터베이스 엔진 중 하나이며 이제 MySQL AB의 바이너리 릴리스 표준 중 하나입니다. 하나는 GPL 인증이고 다른 하나는 인증입니다. 독점 소프트웨어 인증. InnoDB는 트랜잭션 데이터베이스에 선호되는 엔진이며 트랜잭션 보안 테이블(ACID)을 지원합니다. InnoDB는 최대 범위의 동시성을 지원할 수 있는 행 수준 잠금을 지원합니다.

mysql innodb가 뭐야?

이 튜토리얼의 운영 환경: windows7 시스템, mysql8 버전, Dell G3 컴퓨터.

기본적으로 데이터베이스에서 사용되는 스토리지 엔진을 보려면 SHOW VARIABLES LIKE 'storage_engine' 명령을 사용할 수 있습니다.

1. InnoDB 스토리지 엔진

InnoDB는 다음의 데이터베이스 엔진 중 하나입니다. MySQL은 MySQL의 기본 스토리지 엔진이며 MySQL AB에서 발표한 바이너리 표준 중 하나입니다. InnoDB는 Innobase Oy가 개발했으며 2006년 5월 Oracle에 인수되었습니다. 기존 ISAM, MyISAM과 비교했을 때 InnoDB의 가장 큰 특징은 PostgreSQL과 마찬가지로 ACID 호환 트랜잭션(Transaction) 기능을 지원한다는 점이다.

InnoDB는 이중 트랙 라이센스 시스템을 채택합니다. 하나는 GPL 라이센스이고 다른 하나는 독점 소프트웨어 라이센스입니다.

1. InnoDB는 트랜잭션 보안 테이블(ACID)을 지원하는 트랜잭션 데이터베이스용 엔진입니다.

트랜잭션의 ACID 속성: 즉, 원자성, 일관성, 격리, 내구성

: 원자성은 이 진술 세트가 모두 실행되거나 전혀 실행되지 않습니다. 트랜잭션 실행 도중에 오류가 발생하면 데이터베이스는 트랜잭션이 시작된 지점으로 롤백됩니다.

구현: 基는 주로 MySQ 로그 시스템의 Redo 및 UNDO 메커니즘을 기반으로 합니다. 트랜잭션은 선택, 쿼리, 삭제 등의 기능을 갖는 SQL 문의 집합입니다. 각 명령문 실행마다 하나의 노드가 있습니다. 예를 들어, delete 문이 실행된 후 트랜잭션에 기록이 저장됩니다. 이 기록은 우리가 수행한 시간과 작업을 저장합니다. 뭔가 잘못되면 원래 위치로 롤백됩니다. 내가 한 작업은 이미 Redo에 저장되어 있으며 그 후에는 반대로 실행될 수 있습니다.事 b. 일관성: 트랜잭션 시작 전후에 데이터베이스의 무결성 제약 조건이 파괴되지 않았습니다. (예: A가 B에게 돈을 이체한 경우 A가 돈을 공제했지만 B가 받지 못했다는 것은 불가능합니다.) 어떠한 간섭이라도; 다른 책을 읽으려고 커밋된 트랜잭션의 데이터(트랜잭션이 특정 데이터를 여러 번 수정하고 이 트랜잭션의 여러 수정 사항이 아직 커밋되지 않은 경우 동시 트랜잭션이 데이터에 액세스하면 두 개의 트랜잭션이 발생함) 데이터가 일치하지 않음), (다른 트랜잭션에서 커밋되지 않은 더티 데이터 읽기) > 이전 거래를 읽고 동일한 데이터 항목을 쿼리했습니다)

+ 가상 읽기(phantom read)

: 트랜잭션이 독립적으로 실행되지 않을 때 발생하는 현상입니다. (예: 트랜잭션 T1이 "1"에서 테이블의 모든 행의 특정 데이터 항목을 변경합니다. "2"의 작업에 대해 , 트랜잭션 T2는 이 테이블에 또 다른 데이터 항목 행을 삽입하고 이 데이터 항목의 값은 여전히 "1"이며 데이터베이스에 제출됩니다. 트랜잭션 T1을 운영하는 사용자가 새로 수정된 데이터를 보면 수정되지 않은 행이 하나 남아 있는 것을 확인하세요. 실제로 이 행은 마치 환각을 느끼는 것처럼 트랜잭션 T2에서 추가되었습니다 ) (이전 트랜잭션에서 제출한 데이터를 읽어보세요. 일괄 데이터 전체) d. 특정: 트랜잭션이 완료된 후 트랜잭션 데이터베이스의 모든 업데이트가 데이터베이스에 저장됩니다.

2 InnoDB는 기본 스토리지 엔진입니다. RR의 격리 수준에서 한 단계 더 나아가 MVCC(다중 버전 동시성 제어)를 사용하여 반복 불가능한 읽기 문제를 해결하고 갭 잠금(즉, 동시성 제어)을 추가하여 팬텀을 해결합니다. 문제를 읽어보세요. 따라서 InnoDB의 RR 격리 수준은 더 나은 동시성 성능을 유지하면서 실제로 직렬화 수준의 효과를 달성합니다.

MySQL 데이터베이스는 4가지 격리 수준을 제공합니다.

a, 직렬화 가능(직렬화 가능): 더티 읽기, 반복 불가능 읽기 및 팬텀 읽기의 발생을 방지할 수 있습니다. b, 반복 읽기(반복 읽기) ) : 더티 읽기 및 반복 불가능한 읽기의 발생을 방지할 수 있습니다.

c, 커밋된 읽기(커밋된 읽기): 더티 읽기의 발생을 방지할 수 있습니다.

d, 커밋되지 않은 읽기(커밋되지 않은 읽기): 모든 하위 수준 상황은 보장되지 않습니다.

a----d 격리 수준이 높을수록 실행 효율성이 낮아집니다.

3. InnoDB는 행 수준 잠금을 지원합니다. 행 수준 잠금은 동시성을 최대한 지원할 수 있으며 행 수준 잠금은 스토리지 엔진 계층에 의해 구현됩니다.

Lock

: 잠금의 주요 기능은 공유 리소스에 대한 동시 액세스를 관리하여 트랜잭션 격리를 달성하는 것입니다

유형:

공유 잠금(읽기 잠금), 배타적 잠금(쓰기 잠금)

행 수준 잠금(큰 오버헤드, 높은 동시성)은 스토리지 엔진 수준에서 구현됩니다

4. 엄청난 양의 데이터를 처리합니다. CPU 효율성은 디스크 기반 관계형 데이터베이스 엔진과 비교할 수 없습니다5. InnoDB 스토리지 엔진은 MySQL 서버와 완전히 통합되어 있으며 기본 메모리에서 데이터 및 인덱스를 캐싱하기 위해 자체 메모리를 유지합니다. 수영장. InnoDB는 테이블과 인덱스를 논리적 테이블스페이스에 저장하며, 테이블스페이스에는 여러 파일(또는 원본 디스크 파일)이 포함될 수 있습니다.

6. InnoDB는 테이블에 데이터를 저장할 때 각 스토리지에 대한 무결성 제약 조건을 지원합니다. 각 테이블의 기본 키 순서대로 저장됩니다. 테이블 정의 시 기본 키를 지정하지 않으면 기본 키가 지정됩니다. InnoDB는 각 행에 대해 6바이트 ROWID를 생성하여 기본 키로 사용합니다

7. InnoDB는 고성능을 요구하는 많은 대규모 데이터베이스 사이트에서 사용됩니다

8. 예: 테이블에서 count(*)를 선택할 때 InnoDB는 행 수를 계산하기 위해 전체 테이블을 스캔해야 합니다. 전체 테이블을 지울 때 InnoDB는 행을 하나씩 삭제하므로 매우 느립니다. InnoDB를 사용할 때 MySQL은 MySQL 데이터 디렉토리에 ibdata1이라는 10MB의 자동 확장 데이터 파일과 ib_logfile0 및 ib_logfile1이라는 두 개의 5MB 로그 파일을 생성합니다.

2. InnoDB 엔진 저수준 구현

InnoDB에는 두 개의 저장 파일이 있으며 접미사는 .frm과 .idb입니다. .frm은 테이블의 정의 파일이고 .idb는 테이블의 데이터 파일입니다.

1. InnoDB 엔진은 B+Tree 구조를 인덱스 구조로 사용합니다

B-Tree(균형 다중 경로 검색 트리): 디스크와 같은 외부 저장 장치용으로 설계된 균형 검색 트리

시스템 디스크에서 메모리로 데이터를 읽을 때 기본 단위는 디스크 블록 비트입니다. 동일한 디스크 블록에 위치한 데이터는 요청 시가 아닌 한 번에 읽혀집니다.

InnoDB 스토리지 엔진은 페이지를 데이터 읽기 단위로 사용합니다. 페이지는 디스크 관리의 가장 작은 단위입니다. 기본 페이지 크기는 16k입니다.

시스템에서 디스크 블록 하나의 저장 공간은 그렇지 않은 경우가 많습니다. 크므로 InnoDB는 매번 디스크 공간을 신청할 때마다 페이지 크기가 16KB에 도달하는 주소를 가진 일련의 디스크 블록이 있게 됩니다.

InnoDB는 디스크 데이터를 디스크로 읽어올 때 페이지를 기본 단위로 사용합니다. 데이터를 쿼리할 때 페이지의 각 데이터 조각이 데이터 레코드의 위치를 찾는 데 도움이 되면 디스크 I/O가 줄어듭니다. 쿼리 효율성을 향상시키는 시간입니다.

B-Tree 구조의 데이터를 통해 시스템은 데이터가 위치한 디스크 블록을 효율적으로 찾을 수 있습니다.

B-Tree의 각 노드에는 대량의 키워드 정보와 분기가 포함될 수 있습니다. 실제 상황은 다음과 같습니다.

mysql innodb가 뭐야?

각 노드는 디스크 공간 중 하나의 디스크 블록을 차지합니다. 노드에는 두 개의 오름차순 정렬 키가 있고 하위 트리의 루트 노드에 대한 세 개의 포인터가 디스크를 저장합니다. 자식 노드가 위치한 블록입니다.

루트 노드를 예로 들어 보겠습니다. 키워드는 17과 35입니다. P1 포인터가 가리키는 하위 트리의 데이터 범위는 17보다 작습니다. P2포인터가 가리키는 하위 트리의 데이터 범위입니다. 17----35입니다. P3 포인터가 가리키는 하위 트리의 데이터 범위는 35보다 큽니다.

는 키워드 29를 찾는 프로세스를 시뮬레이션합니다.

a입니다. 루트 노드에서 이를 메모리로 읽습니다. [첫 번째 디스크 I/O 작업]

b. 간격(17,35)에서 키워드 29를 비교하고, 디스크 블록 1의 포인터 P2를 찾습니다.

c. , 메모리에 읽어 들입니다. [두 번째 디스크 I/O 작업]

d. 간격(26,30)에서 키워드 29를 비교하고, P2를 기준으로 디스크 블록 3의 포인터 P2를 찾습니다. 포인터, 메모리로 읽어 들입니다. [세 번째 디스크 I/O 작업]

f. 디스크 블록 8의 키워드 목록에서 키워드 29를 찾습니다.

MySQL의 InnoDB 스토리지 엔진은 루트 노드를 메모리에 유지하도록 설계되었습니다. 3개 이하의 트리 깊이를 달성합니다. 즉, I/O가 3회를 초과할 필요는 없습니다.

위 결과를 분석한 결과, 3개의 디스크 I/O 작업과 3개의 메모리 검색 작업이 필요하다는 것을 알았습니다. 메모리 내 키워드는 순서화된 목록 구조이므로 바이너리 검색을 통해 효율성을 높일 수 있으며, 3개의 디스크 I/O 작업이 전체 B-Tree 검색 효율성에 영향을 미치는 결정적인 요소입니다.

B+Tree

B+Tree는 B-Tree 기반의 최적화로, B-Tree의 각 노드에는 키와 데이터가 있으며, 외부 저장소 인덱스 구조를 구현하는 데 더 적합합니다. 각 페이지의 저장 공간은 제한되어 있습니다. 데이터 데이터가 크면 각 노드(즉, 한 페이지)에 저장할 수 있는 키의 수가 매우 적습니다. 저장되는 데이터의 양이 많으면 B-Tree의 깊이도 커지게 되어 쿼리 중 디스크 I/O 횟수가 늘어나 쿼리 효율성에 영향을 미치게 됩니다.

B+Tree에서는 모든 데이터 레코드 노드가 키 값 순서대로 동일한 레이어의 리프 노드에 저장됩니다. 비리프 노드에는 키 값 정보만 저장되므로 각 노드의 저장 용량을 크게 늘릴 수 있습니다. . 키 값의 수는 B+Tree의 높이를 줄입니다.

B+Tree에는 B-Tree를 기반으로 두 가지 변경 사항이 있습니다.

(1) 데이터는 리프 노드에 저장됩니다

(2) 데이터 서로를 가리키는 포인터가 있습니다

B+Tree의 리프가 아닌 노드는 키 값 정보만 저장하므로 각 디스크 블록이 4개의 키 값과 포인터 정보를 저장할 수 있다고 가정하면 B+Tree가 된 후의 구조는 다음과 같습니다.

mysql innodb가 뭐야?