InnoDB 스토리지 엔진 아키텍처에 대해 이야기

InnoDB 스토리지 엔진을 살펴보기 전에 몇 가지 중요한 개념을 추가해 보겠습니다. 이전 기사를 읽지 않았다면 추가 할 수 있습니다.

스토리지 엔진이란 무엇입니까?

대부분의 데이터베이스와 달리 MySQL에는 스토리지 엔진이라는 개념이 있으며 다양한 스토리지 요구 사항에 가장 적합한 스토리지 엔진을 선택할 수 있습니다. 스토리지 엔진은 데이터 저장, 인덱스 작성, 데이터 업데이트 및 쿼리 등을 수행하는 방법입니다. 스토리지 엔진은 라이브러리 기반이 아니라 테이블 기반입니다. 따라서 스토리지 엔진을 테이블 유형이라고도합니다. 플러그인은 스토리지 엔진이 MySQL 데이터베이스의 가장 중요한 기능 중 하나입니다.

일반적인 스토리지 엔진은 무엇입니까?

InnoDB : 是Mysql的默认存储引擎，用于事务处理应用程序，支持外键. 애플리케이션이 트랜잭션 무결성에 대한 요구 사항이 상대적으로 높고 동시 조건에서 데이터 일관성이 필요하고 데이터 작업에 삽입 및 쿼리 사고 외에도 많은 업데이트 및 삭제 작업이 포함되는 경우 InnoDB 스토리지 엔진이 더 적합한 선택입니다. InnoDB 스토리지 엔진은 삭제 및 업데이트로 인한 잠금을 효과적으로 감소시킬뿐만 아니라 트랜잭션의 완전한 제출 및 롤백을 보장합니다 .InnoDB는 청구 시스템 또는 금융 시스템과 같은 높은 데이터 정확성 요구 사항이있는 시스템에 가장 적합합니다.
MyISAM : 애플리케이션이 以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高이면이 스토리지 엔진이 매우 적합합니다.
메모리 : 将所有数据保存在RAM中레코드 및 기타 유사한 데이터 환경을 신속하게 찾아야하는 경우 여러 가지 액세스를 제공 할 수 있습니다. MEMORY의 단점은 对表的大小有限制너무 큰 테이블은 메모리에 캐싱 할 수 없다는 점입니다. 둘째, 테이블의 데이터를 복원 할 수 있는지 확인해야합니다. 테이블의 데이터는 비정상 종료 후에 복원 할 수 있습니다. 데이터 베이스. MEMORY 테이블은 일반적으로 액세스 결과를 빠르게 얻기 위해 자주 업데이트되지 않는 작은 테이블을 업데이트하는 데 사용됩니다.
병합 : 用于将一系列等同的MyISAM表以逻辑方式组合在一起，并作为一个对象引用他们. MERGE 테이블의 장점은 단일 MyISAM 테이블의 크기 제한을 돌파 할 수 있고 여러 디스크에 여러 테이블을 분산하여 MERGE 테이블의 액세스 효율성을 효과적으로 향상시킬 수 있다는 것입니다. 이는 데이터웨어 하우징과 같은 VLDB 환경을 저장하는 데 매우 적합합니다.

다음과 같은 방법으로 데이터베이스의 기본 엔진을 확인할 수 있습니다.

mysql> show variables like '%default_storage_engine%';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | InnoDB |
+------------------------+--------+
1 row in set (0.02 sec)

스토리지 엔진이 필요한 이유는 무엇입니까?

스토리지 엔진은 MySQL에서 데이터의 저장 및 추출을 실제로 담당하며 서버는 API를 통해 스토리지 엔진과 통신합니다. 스토리지 엔진마다 기능이 다르므로 필요에 따라 적절한 스토리지 엔진을 선택할 수 있습니다.

InnoDB 스토리지 엔진의 아키텍처는 무엇입니까?

아키텍처 다이어그램 :

여기에 사진 설명 삽입

다음 단계를 볼 때이 사진을 다시 볼 수 있기를 바랍니다.

데이터를 업데이트하는 SQL이 있다고 가정합니다.

update users set name='小明' where id=10

이 SQL은 데이터베이스 연결을 통과 한 다음 MySQL에 도착합니다. SQL 인터페이스, 파서, 최적화 프로그램 및 실행 프로그램이 끝나면 SQL 문이 구문 분석되고 실행 계획이 생성됩니다. 실행 프로그램은 InnoDB 스토리지 엔진 인터페이스를 호출하여 실행합니다. 아마도 과정입니다

스토리지 엔진은 어떻게 작동합니까?

InnoDB 스토리지 엔진이 업데이트 작업을 수행하게하면 먼저 버퍼 풀로 이동하여 "id = 10"데이터 행이 버퍼 풀에 있는지 확인하고, 존재하지 않으면 디스크에서로드합니다. 그리고 생각해 보면 데이터의 "id = 10"행을 업데이트 할 때 다른 사용자가 동시에 업데이트하는 것을 원하지 않습니다. 이때 배타적 잠금은 이 레코드에 추가되었습니다.

그런 다음 두 번째 부분은 실행 취소 로그 로그에 이전 값을 기록하는 것입니다 (이 로그의 역할은 트랜잭션 롤백을 용이하게하는 것입니다).

위의 두 단계를 완료 한 후 이때 운영 할 데이터는 Buffer Pool의 캐시 페이지에 존재해야하며 (이 개념은 추후 설명) 메모리를 기반으로 수정이 가능합니다. 이때 수정 된 데이터는 메모리에있는 데이터 일 뿐이며 디스크의 데이터는 수정되지 않았으므로 이때 메모리에있는 데이터를 호출합니다.脏数据

다음 단계에서는 메모리에있는 수정 된 데이터를 디스크로 플러시해야합니다. 어떻게 작동하는지 살펴 보겠습니다. 먼저이 작업을 리두 로그 버퍼에 在提交事务之后기록하고 특정 전략에 따라 리두 로그 버퍼의 데이터를 디스크의 디스크 파일로 전송합니다. 이 시점에서 분명히 생각할 것입니다. 왜이 로그가 있습니까? 실제로는이 상황을 처리하는 것입니다. 메모리의 데이터를 수정하고 MySQL이 갑자기 충돌하면 메모리에서 수정 된 데이터가 디스크에 적시에 기록되지 않은 데이터가 있습니다. 리두 로그를 사용하면 메모리의 데이터가 디스크로 플러시 할 시간이 없더라도 리두 로그 로그에 들어가는 한 중요하지 않습니다. 왜냐하면 MySQL이 다시 시작되면 MySQL이 시작되기 전에 데이터를 복원하기 때문입니다. 리두 로그 작업의 정보를 기반으로 한 다운 타임.

앞서 언급했듯이 트랜잭션을 커밋 한 후 MySQL은 특정 전략에 따라 Redo 로그 버퍼의 데이터를 디스크로 플러시합니다. 여기서 "전략"은 매개 변수로 innodb_flush_log_at_trx_commit구성 됩니다 . 다음과 같은 방식으로 볼 수 있습니다. My own MySQL now 다음과 같은 전략을 사용합니다.

mysql> show variables like '%innodb_flush_log_at_trx_commit%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.01 sec)

innodb_flush_log_at_trx_commit = 0

트랜잭션을 커밋 할 때 리두 로그 버퍼의 데이터는 디스크로 플러시되지 않습니다. 트랜잭션을 성공적으로 커밋 한 후 다운 타임이 발생하면 메모리의 다시 실행에서 데이터 손실이 발생합니다.
innodb_flush_log_at_trx_commit = 1

이것은 MySQL의 기본 상황입니다. 트랜잭션을 커밋 한 후에는 메모리에서 디스크로 다시 실행해야합니다. 트랜잭션이 성공적으로 커밋되는 한 디스크의 다시 실행 로그에 해당 데이터가 있어야합니다. 상황이 말했다.
innodb_flush_log_at_trx_commit = 2

트랜잭션을 커밋 한 후 리두 로그가 즉시 디스크로 플러시되지 않고 os 캐시 메모리 캐시에 남아있을 수 있습니다. 트랜잭션이 성공적으로 커밋되고 다운 타임이 발생하면 리두 로그가 손실됩니다.

위의 세 가지 전략에 대해 이야기 한 후 이제 각각의 장점과 단점을 요약 할 수 있습니다.

전략	이점	불리
0	트랜잭션이 제출 될 때마다 디스크에 데이터가 기록되지 않기 때문에 쓰기 속도가 빠릅니다.	데이터 보안은 최악이며 트랜잭션 커밋 후 다운 타임에 대처할 수 없습니다.
1	트랜잭션이 커밋 될 때마다 데이터가 디스크에 기록되므로 쓰기 성능이 최악입니다.	최고의 데이터 보안
2	쓰기 성능이 가장 높지는 않지만 매우 높습니다.	트랜잭션이 제출 된 후 데이터가 손실되지 않는다는 보장은 없지만 데이터는 최대 1 초 이내에만 손실되며 보안은 0보다 훨씬 높습니다.

MySQL의 InnoDB 엔진