mysql 스토리지 엔진: myIsam과 innodb의 차이점

MySQL에는 여러 스토리지 엔진이 있으며 MyISAM과 InnoDB는 일반적으로 사용되는 두 가지 엔진입니다. 다음은 이 두 엔진에 대한 몇 가지 기본 개념입니다(자세한 소개는 아님).

MyISAM은 MySQL의 기본 스토리지 엔진으로, 기존 ISAM 유형을 기반으로 하며 전체 텍스트 검색을 지원하지만 트랜잭션에 안전하지 않으며 외래 키를 지원하지 않습니다. 각 MyISAM 테이블은 세 개의 파일에 저장됩니다. frm 파일은 테이블 정의를 저장하고, 데이터 파일은 MYD(MYData)이고, 인덱스 파일은 MYI(MYIndex)입니다.

InnoDB는 롤백, 충돌 복구, 다중 버전 동시성 제어, ACID 트랜잭션 및 행 수준 잠금을 지원하는 트랜잭션 엔진입니다(InnoDB 테이블의 행 잠금은 절대적이지 않습니다. MySQL이 SQL 실행 시 스캔을 결정할 수 없는 경우) 문 범위 내에서 InnoDB 테이블은 유사한 작업 중에 SQL 문과 같은 전체 테이블을 잠그고 Oracle 유형과 일치하는 잠금 없는 읽기 방법을 제공합니다. InnoDB는 여러 파일을 포함할 수 있는 테이블스페이스에 테이블과 인덱스를 저장합니다.

핵심 차이점

MyISAM은 트랜잭션에 안전하지 않은 반면 InnoDB는 트랜잭션에 안전합니다.

MyISAM 잠금 세분성은 테이블 수준인 반면 InnoDB는 행 수준 잠금을 지원합니다.

MyISAM은 전체 텍스트 유형의 인덱스를 지원하지만 InnoDB는 전체 텍스트 인덱스를 지원하지 않습니다.

MyISAM은 상대적으로 간단하므로 효율성 측면에서 InnoDB보다 낫습니다. 소규모 애플리케이션에서는 MyISAM 사용을 고려할 수 있습니다.

MyISAM 테이블은 파일로 저장됩니다. 크로스 플랫폼 데이터 전송에서 MyISAM 스토리지를 사용하면 많은 문제가 해결됩니다.

InnoDB 테이블은 MyISAM 테이블보다 더 안전합니다. 데이터가 손실되지 않도록 하면서 비트랜잭션 테이블을 트랜잭션 테이블로 전환할 수 있습니다(alter table tablename type=innodb).

애플리케이션 시나리오

MyISAM은 비트랜잭션 테이블을 관리합니다. 고속 저장 및 검색은 물론 전체 텍스트 검색 기능도 제공합니다. 애플리케이션이 많은 수의 SELECT 쿼리를 수행해야 하는 경우 MyISAM이 더 나은 선택입니다.

InnoDB는 트랜잭션 처리 애플리케이션에 사용되며 ACID 트랜잭션 지원을 포함한 다양한 기능을 갖추고 있습니다. 애플리케이션이 많은 수의 INSERT 또는 UPDATE 작업을 수행해야 하는 경우 다중 사용자 동시 작업의 성능을 향상시킬 수 있는 InnoDB를 사용해야 합니다.

Mysql 스토리지 엔진 및 인덱스

데이터베이스에는 인덱스가 있어야 합니다. 인덱스가 없으면 검색 프로세스는 순차 검색이 되며 O(n)의 시간 복잡도는 거의 견딜 수 없습니다. 키가 트리의 노드에 저장되어 있는 한, 단일 키로만 구성된 테이블이 B+ 트리를 사용하여 어떻게 인덱싱될 수 있는지 상상하기는 매우 쉽습니다. 데이터베이스 레코드에 여러 필드가 포함된 경우 B+ 트리는 기본 키가 아닌 필드가 검색되면 기본 키 인덱스가 해당 기능을 잃고 다시 순차 검색이 됩니다. 이때, 조회하려는 두 번째 컬럼에는 두 번째 인덱스 세트를 구축해야 한다. 이 인덱스는 독립적인 B+ 트리로 구성됩니다. 동일한 테이블 데이터 집합에 액세스하는 여러 B+ 트리 문제를 해결하는 두 가지 일반적인 방법이 있습니다. 하나는 클러스터형 인덱스(클러스터형 인덱스)라고 하고 다른 하나는 비클러스터형 인덱스(보조 인덱스)라고 합니다. 이 두 이름은 모두 인덱스라고 부르지만 별도의 인덱스 유형이 아니라 데이터 저장 방식이다. 클러스터형 인덱스 저장의 경우 행 데이터와 기본 키 B+ 트리가 함께 저장되며, 보조 키 B+ 트리는 보조 키만 저장하고 기본 키와 비기본 키 B+ 트리는 거의 두 가지 유형의 트리입니다. 비클러스터형 인덱스 저장소의 경우 기본 키 B+ 트리는 기본 키 대신 리프 노드의 실제 데이터 행에 대한 포인터를 저장합니다.

InnoDB는 기본 키를 B+ 트리로 구성하기 위해 클러스터형 인덱스를 사용하고 행 데이터는 리프 노드에 저장됩니다. 기본 키를 찾기 위해 "where id = 14" 조건을 사용하면 다음과 같이 검색됩니다. B+ 트리 알고리즘은 해당 리프 노드를 찾은 다음 행 데이터를 얻을 수 있습니다. Name 열에 대해 조건부 검색을 수행하는 경우 두 단계가 필요합니다. 첫 번째 단계는 보조 인덱스 B+ 트리에서 Name을 검색하고 해당 리프 노드에 도달하여 해당 기본 키를 얻는 것입니다. 두 번째 단계에서는 기본 키를 사용하여 기본 인덱스 B+ 트리 종에 대해 또 다른 B+ 트리 검색 작업을 수행하고 마지막으로 리프 노드에 도달하여 전체 데이터 행을 얻습니다.

MyISM은 비클러스터형 인덱스의 두 B+ 트리를 사용합니다. 노드의 구조는 완전히 동일하지만 기본 키 인덱스 B+ 트리의 노드는 다릅니다. 기본 키와 보조 키 인덱스를 저장합니다. B+ 트리는 보조 키를 저장합니다. 테이블 데이터는 별도의 장소에 저장됩니다. 두 B+ 트리의 리프 노드는 주소를 사용하여 실제 테이블 데이터를 가리킵니다. 두 키 사이에는 차이가 없습니다. 인덱스 트리는 독립적이므로 보조 키를 통한 검색에는 기본 키에 대한 인덱스 트리에 대한 액세스가 필요하지 않습니다.

이 두 인덱스의 차이점을 좀 더 명확하게 설명하기 위해 아래와 같이 4행의 데이터를 저장하는 테이블을 상상해 보겠습니다. 그 중 Id는 1차 인덱스 역할을 하고, Name은 2차 인덱스 역할을 합니다. 다이어그램은 클러스터형 인덱스와 비클러스터형 인덱스의 차이점을 명확하게 보여줍니다.

클러스터형 인덱스에 중점을 두었습니다. 보조 인덱스를 사용하여 검색할 때마다 두 번의 과정을 거쳐야 하기 때문에 클러스터형 인덱스의 효율성이 비클러스터형 인덱스에 비해 확실히 떨어지는 것 같습니다. B+ 트리 검색은 불필요한 것 아닌가요? 클러스터형 인덱스의 장점은 무엇입니까?

1 행 데이터와 리프 노드가 함께 저장되므로 기본 키와 행 데이터가 함께 메모리에 로드됩니다. 리프 노드를 찾으면 행 데이터를 그에 따라 즉시 반환할 수 있습니다. 기본 키 ID에 데이터를 더 빠르게 얻을 수 있습니다.

2 보조 인덱스는 주소 값을 포인터로 사용하는 대신 기본 키를 "포인터"로 사용하므로 행 이동이나 데이터 페이지 시 보조 인덱스의 유지 관리 작업을 줄일 수 있다는 장점이 있습니다. 기본 키 값을 사용할 때 포인터를 사용하면 보조 인덱스가 더 많은 공간을 차지하게 됩니다. 장점은 행을 이동할 때 InnoDB가 보조 인덱스의 "포인터"를 업데이트할 필요가 없다는 것입니다. 즉, 데이터베이스의 데이터가 수정됨에 따라(이전 B+ 트리 노드 분할 및 페이지 분할) 행의 위치(구현 시 16K 페이지를 통해 위치, 이후에 설명)가 변경됩니다. 클러스터형 인덱스를 사용할 수 있습니다. 기본 키 B+ 트리의 노드가 어떻게 변경되더라도 보조 인덱스 트리는 영향을 받지 않습니다.

그래서 수백만 개의 데이터와 대용량 데이터의 경우 mysql innoDB의 인덱스 성능이 더욱 좋습니다!

위 내용은 mysql 스토리지 엔진: myIsam과 innodb의 차이점의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!