InnoDB 스토리지 아키텍처

MySQL 서버는 기본적으로 사람의 머리 역할을 담당하는 MySQL 엔진과 손발 역할을 담당하는 스토리지 엔진으로 구분할 수 있다. 그중 스토리지 엔진의 경우 InnoDB와 MyISAM이 있는데, InnoDB를 8.0 이후부터는 기본으로 제공하고 있다.

따라서 대체로 InnoDB를 거의 사용하게 되는데, 해당 아키텍처에 대해서는 자세히 알지 못하고 사용하는 경우가 많다.

InnoDB 스토리지 엔진의 특성

먼저, InnoDB가 가지고 있는 특성에 대해서 알아보자.

InnoDB의 모든 테이블은 기본적으로 PK를 기준으로 클러스터링되어 저장된다. (물리적으로)
- 따라서, PK를 사용한 레인지 스캔은 상당히 빨리 처리될 수 있다.
모든 세컨더리 인덱스는 레코드의 주소 대신 PK의 값을 논리적인 주소로 사용한다.
MyISAM 스토리지 엔진에서는 클러스터링 키를 지원하지 않는다.

MyISAM이나 MEMORY 테이블에서는 지원하지 않는다.
InnoDB에서는 부모 테이블과 자식 테이블 모두 해당 칼럼에 인덱스 생성이 필요하고, 변경 시에는 반드시 부모 테이블이나 자식 테이블에 데이터가 있는지 체크하는 작업이 필요하므로 잠금이 여러 테이블로 전파되고, 이로 인해 데드락이 발생할 때가 많으므로 개발할 때도 외래 키의 존재에 주의하는 것이 좋다.

일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능
가장 큰 목적 : 잠금을 사용하지 않는 일관적인 읽기 제공
InnoDB는 언두로그를 이용해 해당 기능을 구현한다.
Multi Version이라는 뜻은 하나의 레코드에 대해 여러 개의 버전이 동시에 관리된다는 의미.
- 즉, 하나의 레코드에 대한 여러 개의 언두 로그를 유지하고 있으며 자연히 언두 영역이 저장되는 시스템 테이블스페이스의 공간이 많이 늘어나는 상황이 발생할 가능성이 있다.
- 언두 영역을 삭제하는 기준은 해당 언두 영역을 필요로 하는 트랜잭션이 더는 없을 시기를 말한다.

위의 MVCC를 통하여 구현하는 기능
잠금을 걸지 않기 때문에 InnoDB에서 순수한 SELECT 작업은 다른 트랜잭션의 변경 작업과 관계없이 항상 잠금을 대기하지 않고 바로 실행된다. (SERIALIZABLE 격리 수준 제외)

InnoDB 스토리지 엔진은 데드락 감지 스레드를 가지고 있어 주기적으로 감지하여 그중 하나를 강제로 종료한다.
종료되는 스레드는 롤백이 가장 용이한(복구 작업이 가장 적은) 스레드로, 언두 로그 레코드를 더 적게 가진 트랜잭션이 일반적으로 롤백의 대상이 된다.

InnoDB 스토리지 엔진은 트랜잭션과 격리 수준을 보장하기 위해 DML(INSERT, UPDATE, DELETE)로 변경되기 전 데이터를 별도로 백업한다. 이렇게 백업된 데이터를 언두 로그라고 한다.

트랜잭션 보장

격리 수준 보장

특정 커넥션에서 데이터를 변경하는 도중 다른 커넥션에서 데이터를 조회하면 트랜잭션 격리 수준에 맞게 변경 중인 레코드를 읽기 않고 언두 로그에 백업해둔 데이터를 읽어 반환한다.

지금까지는 MyISAM이 기본 스토리지 엔진인 경우가 많았다.
MySQL 5.5부터 InnoDB가 기본으로 채택되었으나 일부는 MyISAM을 사용하고 있었고, 8.0부터 모든 시스템 테이블이 InnoDB로 변경되었다.
이렇게 8.0 이후로 InnoDB스토리지 엔진에 대한 기능이 개선되는 만큼 MyISAM 스토리지 엔진만이 가지는 장점이 없는 상태이다. 이후 버전에서는 없어질 것으로 예상된다.

REAL MySQL 4장