mysql 스토리지 엔진-InnoDB에 대한 매우 자세한 설명

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

SHOW VARIABLES LIKE 'storage_engine';

1. InnoDB 스토리지 엔진

1 InnoDB는 트랜잭션 데이터베이스에 선호되는 엔진입니다.

트랜잭션을 지원합니다. 안전 테이블(ACID)

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

a.원자성: 원자성은 트랜잭션이 실행되는 경우 이 명령문 세트가 모두 실행되거나 아무것도 실행되지 않음을 의미합니다. 실행 도중에 오류가 발생하면 데이터베이스는 트랜잭션이 시작된 지점으로 롤백됩니다.

Implementation: 주로 MySQ 로그 시스템의 다시 실행 및 실행 취소 메커니즘을 기반으로 합니다. 트랜잭션은 선택, 쿼리, 삭제 등의 기능을 갖는 SQL 문의 집합입니다. 각 명령문 실행마다 하나의 노드가 있습니다. 예를 들어, 삭제 문이 실행된 후 트랜잭션에 기록이 저장됩니다. 이 기록은 우리가 수행한 시간과 작업을 저장합니다. 뭔가 잘못되면 원래 위치로 롤백됩니다. 내가 한 일은 Redo에 저장되어 있고, 그 후에는 반대로 실행될 수 있습니다.

b.Consistency: 트랜잭션 시작 및 종료 전후에 데이터베이스의 무결성 제약 조건을 위반하지 않습니다. (예: A가 B에게 돈을 이체하는 경우 A가 돈을 공제했지만 B가 받지 못한 것은 불가능합니다.)

c.Isolation: 동시에 한 거래에서만 동일한 금액을 요청할 수 있습니다.

격리를 고려하지 않으면 여러 가지 문제가 발생합니다.

i, Dirty read: 한 트랜잭션 중에 커밋되지 않은 다른 트랜잭션에서 데이터를 읽는 것을 말합니다. 트랜잭션이 진행 중입니다) 특정 데이터를 여러 번 수정했는데 이 트랜잭션의 여러 수정 사항이 아직 커밋되지 않았습니다. 이때 동시 트랜잭션이 데이터에 액세스하므로 두 트랜잭션에서 얻은 데이터가 일치하지 않게 됩니다. ; (다른 트랜잭션 읽기) 트랜잭션에 의해 커밋되지 않은 더티 데이터)

ii, 반복 불가능한 읽기: 데이터베이스의 특정 데이터에 대해 트랜잭션 범위 내의 여러 쿼리가 다른 데이터 값을 반환하기 때문입니다. 쿼리 간격 동안 다른 트랜잭션이 수정되어 제출됨(이전 트랜잭션에서 제출한 데이터를 읽고 동일한 데이터 항목을 쿼리함)

iii, 가상 읽기(팬텀 읽기): 발생하는 트랜잭션입니다. 트랜잭션이 독립적으로 실행되지 않을 때 이 현상(예: 트랜잭션 T1이 테이블의 모든 행에 있는 데이터 항목을 "1"에서 "2"로 수정한 다음 트랜잭션 T2가 데이터 항목의 행을 테이블에 삽입합니다. 데이터 항목의 값은 여전히 ​​"1"이고 데이터베이스에 제출됩니다. 사용자 운영 트랜잭션 T1이 방금 수정된 데이터를 보면 실제로 이 행이 아직 수정되지 않은 행이 하나 있음을 알 수 있습니다. 마치 생성된 것처럼 트랜잭션 T2에서 추가되었습니다. (전체 데이터 배치에 대해 이전 트랜잭션에서 제출한 데이터를 읽습니다.)

d.Persistence: 트랜잭션이 완료된 후 모든 업데이트 트랜잭션에 의해 데이터베이스에 저장되면 데이터베이스에 저장되며 롤백할 수 없습니다

2.InnoDB는 mySQL의 기본 스토리지 엔진입니다

기본 격리 수준은 RR이며 격리 수준 RR 아래에서는 한 단계 더 나아가 MVCC(다중 버전 동시성 제어)를 통해 반복 불가능한 읽기 문제를 해결하고, Gap 잠금(즉, 동시성 제어)을 통해 팬텀 읽기 문제도 해결합니다. 따라서 InnoDB의 RR 격리 수준은 더 나은 동시성 성능을 유지하면서 실제로 직렬화 수준의 효과를 달성합니다.

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

a, 직렬화 가능(직렬화): 더티 읽기, 반복 불가능한 읽기 및 팬텀 읽기의 발생을 방지할 수 있습니다. Serializable（串行化）：可避免脏读、不可重复读、幻读的发生；

b、Repeatable read（可重复读）：可避免脏读、不可重复读的发生；

c、Read committed（读已提交）：可避免脏读的发生；

d、Read uncommitted

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

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

d, 커밋되지 않은 읽기(커밋되지 않은 읽기): 가장 낮은 수준, 어떤 상황에서도 보장되지 않음

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

3. InnoDB는 행 수준 잠금을 지원합니다

.

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

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

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

MySQL 잠금의 강점: 테이블 수준 잠금( 낮은 오버헤드, 낮은 동시성)은 일반적으로 서버 계층에서 구현됩니다

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

4 InnoDB는 엄청난 양을 처리하는 가장 큰 데이터베이스입니다. 성능을 위해 설계되었습니다 .

CPU 효율성은 디스크 기반 관계형 데이터베이스 엔진과 비교할 수 없습니다.

5. InnoDB 스토리지 엔진은 MySQL 서버와 완전히 통합됩니다. InnoDB 스토리지 엔진은 자체 버퍼 풀에서 데이터 및 인덱스를 캐싱하기 위해 유지됩니다. . InnoDB는 테이블과 인덱스를 논리적 테이블 공간에 배치하고 테이블 공간에는 여러 파일(또는 원시 디스크 파일)이 포함될 수 있습니다.

🎜6🎜, 🎜InnoDB는 외래 키 무결성 제약 조건을 지원합니다🎜🎜

테이블에 데이터를 저장할 때, 테이블 정의 시 기본키를 지정하지 않으면 각 테이블은 기본키 순서대로 저장됩니다. InnoDB는 각 행에 대해 6바이트 ROWID를 생성하여 기본 키로 사용합니다

7. InnoDB는 고성능이 필요한 많은 대규모 데이터베이스 사이트에서 사용됩니다# 🎜 🎜#

8. InnoDB는 테이블의 행 수를 저장하지 않습니다(예: 테이블에서 count(*)를 선택할 때 InnoDB는 행 수를 계산하기 위해 전체 테이블을 스캔해야 합니다. 전체 테이블을 지울 때 InnoDB는 행을 하나씩 삭제하는데 이는 매우 느립니다. 확장 데이터 파일과 ib_logfile0 및 ib_logfile1

이라는 두 개의 5MB 로그 파일이 있습니다. InnoDB 엔진의 기본 구현

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

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

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

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

InnoDB 스토리지 엔진은 페이지를 데이터 읽기 단위로 사용합니다. 페이지는 디스크 관리의 최소 단위입니다.

1개의 디스크 블록의 저장 공간입니다. 시스템은 그다지 크지 않은 경우가 많기 때문에 InnoDB가 디스크 공간을 적용할 때마다 주소가 있는 여러 개의 연속 디스크 블록을 사용하여 16KB의 페이지 크기에 도달합니다.

InnoDB는 디스크 데이터를 디스크로 읽을 때 페이지를 기본 단위로 사용합니다. 데이터를 쿼리할 때 페이지의 각 데이터 조각이 데이터 레코드의 위치를 ​​찾는 데 도움이 될 수 있습니다. 디스크 I/O 수를 줄이고 쿼리 효율성을 향상시킵니다.

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

B-Tree의 각 노드에는 많은 수의 데이터가 포함될 수 있습니다. 실제 상황에 따른 키워드 정보 및 분기(예:

각 노드는 디스크 공간의 한 블록을 차지하며 오름차순으로 정렬된 두 개의 키와 한 노드에 3개 하위 트리의 루트 노드에 대한 포인터 포인터는 하위 노드가 위치한 디스크 블록의 주소를 저장합니다.

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

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

a. 루트 노드를 기반으로 디스크 블록 1을 찾아 메모리로 읽습니다. [최초의 디스크 I/O 작업]

b. 간격(17,35)에서 키워드 29를 비교하고 디스크 블록 1의 포인터 P2를 찾습니다. c. P2 포인터에 따라 디스크 블록 3을 찾아 메모리로 읽습니다. [두 번째 디스크 I/O 작업]

d. 간격(26,30)에서 키워드 29를 비교하고 디스크 블록 3의 포인터 P2를 찾습니다. . P2 포인터에 따라 디스크 블록 8을 찾아 메모리에 읽습니다. [디스크 I/O 작업 3차]

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

MySQL의 InnoDB 스토리지 엔진을 설계 중입니다. 루트 노드는 항상 메모리에 상주하므로 우리는 3개 이하의 트리 깊이, 즉 3개 이하의 I/O를 달성하려고 노력합니다.

위 결과를 분석한 결과 3개의 디스크가 발견되었습니다. I/O에는 필수 작업과 세 가지 메모리 조회 작업이 있습니다. 메모리 내 키워드는 순서화된 목록 구조이므로 바이너리 검색을 통해 효율성을 높일 수 있으며, 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에서는 두 가지 검색 작업을 수행할 수 있습니다. 하나는 기본 키에 대한 범위 검색 및 페이징 검색이고, 다른 하나는 루트 노드에서 시작하는 무작위 검색입니다.

B+Tree in InnoDB

InnoDB는 ID로 인덱싱된 데이터 저장소입니다

InnoDB 엔진을 사용하는 데이터 저장소 파일이 두 개 있는데, 하나는 정의 파일이고 다른 하나는 데이터 파일입니다.

InnoDB는 B+Tree 구조를 통해 ID에 인덱스를 구축한 후 리프 노드에 레코드를 저장합니다

인덱싱된 필드가 기본 키 ID가 아닌 경우 해당 필드에 대한 인덱스를 생성한 다음 레코드의 기본 키를 리프 노드에 저장한 후 기본 키 인덱스를 통해 해당 레코드를 찾습니다.

관련 질문이 더 필요하시면 PHP 중국어 웹사이트를 방문하세요: PHP 비디오 튜토리얼

위 내용은 mysql 스토리지 엔진-InnoDB에 대한 매우 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!